Procedurally Challenged: Downie's Blog

Qt: Nokia's Best Since Snake

2011-06-22T12:42:00.000-07:00

I took my first tentative steps into Qt this week at work. We are using it to (ironically) create a UI interface for our GUI designer. I have to say it has some really nice features and the IDE is pretty good to. The reflective stuff is really powerful (although it does make using it in anything except QtCreator a bit of a pain); and it is something I would really like to incorporate into our own engine. It adds features to C++ that you normally only get with C#, ObjC etc; such as linking functions to actions in the UI designer. The loose model of connecting slots (i.e. methods) with signals (i.e events) really helps to create modular code.

Currently our engine uses run time hashing to generate RTTI information for objects (i.e. in a IsA fashion); however it would definetely benifit from doing that offline and would allow for more in depth RTTI (including accessing GUI objects from the tool as if they were objects in code). Also ourGUI designer tool generates an XML output that can be loaded at run-time, I might at some point use the Qt method of generating side by side code straight into C++.

Android - Setting the industry back 10 years

2011-03-24T14:57:00.000-07:00

Has anyone else noticed that Android is actually J2ME in disguise? People keep saying that Android is the next big thing but actually it just the thing that everyone has. Everyone has a washing machine but I don't make games for that!

You can't say the guys at Google haven't given us a sporting chance though. Either do the game in Java with (ironically as it's Java) a porting nightmare, not to mention performance that would make East Fife FC ashamed...or strap on your wellies and enter the dragon infested world of the NDK. We wanted to create a pipeline for rapid porting of iOS games to Android so we thought (somewhat naively) "hey the NDK is C++, that means it will just work! Won't it?". The short answer is no...no it won't. There is no native STL support and of the two main STL ports one supports wstring and one supports exceptions and apparently the two are mutually exclusive. Who would have thought it.

Actually I exageratte, it is possible but I thought we had moved beyond the need for custom makefiles and hokey compilers that don't support full C++ and code that has to be compiled to a library to run...but I suppose anything is better than java. So once your cross-platform code compiles your good to go surely? All you need to do is swap out the iOS/PSP/DS backend and pop the Android one in. I mean the latest NDK supports native GL, audio, file management, activities, input; you don't actually need to interface with Java for anything! Except in true J2ME, sorry Android style only 2% of people have the latest firmware and the older NDK supports bugger all! Ahh Java you wiley fox I knew you would eat my lovely C++Chickens the moment my back was turned! Seriously though, how can an update thats been out for months not be on more devices. iOS 4.0 is now on 90% of devices so why not Android? Apparently there are more Android devices in the world than there are atoms in the sun. So why do so few have the latest release. I would have got away with it if it weren't for those meddlesome phone manufacturers...and those pesky network carriers too!

So it's all gravy. We have our back end. The games ported and running. We have reduced the poly count on all our models so that everything looks like mashed potato. Just a quick compatability test then we are ready to launch! This is where Android really delivers. You see they have a very, very strict policy on hardware, particularly screen size. So you test on a G1 (and cry), and on a nexus and a droid and on an HTC. All good..."what's that Sony Ericsson? You want to make what? It's not really allowed but seeing as it's you...".

Yep thats right a 240x320 device. Are you sure you aren't J2ME? Because by the time the games gone onto the Xperia mini it might aswell have been ported to the your wristwatch. Don't worry though...no-one will notice the lag or the bad graphics unless they are the hollow man! The only way to see the screen and actually play the game simultaneously is to rig an elaborate pully system to your 2 year old childs hands.

Ahh the final stage - submission. No pesky TRC's here to trip you up. No dodgy provisioning files etc. Just pick a handful of stores or alternatively just post a helpful link on facebook and everyone will be able to steal (sorry buy) your game. But wait... "Oooh Amazon have a store. Amazon are nice...what's that? The version on amazon must be of the same quality as the highest end version of the app!" "Oh well that PS3 port is going to look interesting"

To sum up, Android makes me cry. Unfortunately I seem to be in the minority. Ahh well... Google don't worry I still love your search engine and your mail.

OpenGL ES 2.0 - I can't quite put my finger on it

2010-11-28T02:23:00.001-08:00

Finally got my first taste of OpenGL ES 2.0 and GLSL this week. I have to say it was bittersweet. I think mostly because it wasn't DirectX. I understand that splitting and compiling the shader program as multiple files means that vertex shaders can be re-used. I understand that having the shader files as text allows you to create shaders in code. I understand that enabling alpha, depth, etc outside the shader allows for hardware acceleration. However, it all just feels a bit meh. That's GL in a nutshell...meh. What with it's C API, stupid extensions and state system it just never felt as polished as say DX 10.

That being said ES is a cute koala compared with the diseased rhino that is GL.

This week I was converting my material system from 1.1 to 2.0. My material files allow for the render states to be set, lighting values, textures and the shader program. Another benefit of using separate VS and PS is that I can cache the two compiled files individually and also cache the combined shader program. Caching can be critical as Apple don't allow you to compile shaders offline.

I didn't really know the best way to handle shader parameters. For instance a user applies a toon shader to one object and a water effect to another; how do you determine what values to pass to the shader? I could use the shader variable query on a host of pre-determined values but this seems a bit naive and the chances of it working for a developers custom shaders are 0.23%.

I have decided this calls for more research...Ogre my old friend how do you do it?

Location:Bed

U-turn if you want to…This lady’s not for turning

2010-09-13T10:29:00.001-07:00

In the biggest u-turn since Paul O’Grady re-joined ITV; Apple have decided to embrace 3rd party developer tools for their iDevices. This is good news for developers (not because of Flash) but as they will now be able to use engines without fear of rejection. I hope that Apple keep their word with regard to quality control; because as much as I disagree with Mr Jobs about Flash being crap it has pretty much blown the barrier to entry away. However, I hope they don’t reject Flash games out of hand. There are many good Flash games far superior to some of the fart apps currently on the AppStore.

I wonder what has prompted this change of heart? Is it pressure from developers? Or is it the Android elephant in the room? One can only speculate…

Realtime Worlds - On the slab

2010-09-05T12:21:00.000-07:00

What we do at Tag is a million miles from what happens at Realtime Worlds (even if our studio is only 5 mins away), but when it was announced that RTW was going into administration, most of us felt it was a huge blow. The Dundee games industry suffered a massive hit and it may well have changed the shape of the games industry in Scotland forever. Reading through a lot of the 'post-mortems' from ex RTW employees it seems most of them agree that RTW was a dinosaur. I don't believe we will ever see another company in Dundee that limits itself to AAA titles. Most of us have accepted that this is no longer the domain of indie companies and trying to play with the big boys in that market is almost impossible. Evolve or die. Gaming is no longer the domain of bedroom-bound, teenage boys. Why limit yourself when you have a direct route to a mass-market of social, hand-held and mobile gamers?

For many the demise of RTW was inevitable but I for one am gutted that Scotland has lost one of it's few AAA studios. Really though it's the dinosaur I am lamenting. When I was at uni everyone wanted to work for RTW etc and make huge budget titles. Now many of us are never going to get the chance. Although mobile/social/DL has been the saviour of the industry in many respects; it saddens me that I won't be able to walk into Game, point at the #1 slot in the shelf and say "I made that".

If you get a chance you should Google for some of the post-mortems. Scathing I think the term is...

Guess It's been a while

2010-09-03T01:52:00.000-07:00

It's been ages since my last post, due to work commitments and my lack of internet. However I thought I'd mark my return by saying how awesome the Epic Citadel tech demo is on iDevices. It makes me yearn for some shader action!

I've been spending a great deal of time trying to get a usuable GL framework up and running on Android. Android is really beginning to piss me off. I appreciate that Java is portable Google, but can we at least have a decent JIT compiler! My motto has always been "real men manage their own memory".

Lots of developers seem to be disgruntled at the lack return for investment with Android apps. It's hardly worth the time. But that's what you get when you make an open source platform: 70% of apps of the Android Market are free! No wonder it's impossible to make any money. Unless you have tech that allows you to easily port from iDevices to Android, it is going to be difficult to make any money.

Shame though cos Google have managed to cut out alot of the hassle associated with developing for iDevices.

Did manage to have a wee shot of Windows 7 Mobile development this week. It is not much different than XNA; and I have to say I'm impressed by my initial experience. Everything came in the one package, no need to find an IDE, get the SDK and drivers etc. Fingers crossed that Windows 7 Mobile takes off.

Oh I'm also on Twitter you can follow me as Rev_Downie

Astro Ranch – A Long Time Coming…

2010-02-16T15:26:00.001-08:00

The culmination of a lot of hard work and even more takeaways! Anyone who has an iPhone or iTouch get it! It’s addictive!

More than a farming game; it has fishing an gold panning mini games, plus quests and social features!

Plus the into movie!

Not the most exciting trailer lol…

Unity…It’s Unreal

2009-11-15T14:25:00.001-08:00

Like buses, two great game development engines have come along at once. So this week I’ve been playing around with both of them to see which is better and, to be honest; I’m unsure.

I find that Unity is much simpler to use with a better interface. It is easier to attach scripts to objects and to create terrain. It’s a bonus that the scripting languages are Javascript and C# compared to Unreal script. However UDK has more features and a lot more built-in assets; which is great for coders like me : ), yet means that everythiing looks like an Unreal tournament rip-off.

I can’t get over the sense of cheating though. With both engines I created a terrain, clicked play and before I knew it I had a physics controller running around screen, interacting with the environment. With Unreal you even get a frontend menu and a FPS character with a gun! Makes my terrain generator seem sadly pointless…

Anywhere here’s a clip of a destructible wall I made in UDK. Make up your own mind.

Delegates Hurt My Face

2009-10-25T15:12:00.001-07:00

Now that I’m a fully fledged iPhone developer I finally decided to get my head round delegates as they seem to be the cock and balls of iPhone programming. Coming from a largely C++ background I wrongly assumed that delegates were just callbacks in a silly mac outfit. Apparently I was wrong. So I thought I’d post a an article about delegates (as much for me as) for anyone else struggling to come to terms with them.

As the name suggests, delegates are a way of offloading work to another object. The best way to demonstrate this is with an example. Say an application for the iPhone has a class/library that handles user events; such as button presses. These events will register for any application but will mean different things to different objects. The user class will register the button event and delegate the functionality to a different class. Think of them like helper functions to the main interface. This class will interpret the button press and perform some action (perhaps playing a song etc).

Here’s some ObjC code that sets up a simple delegate (Not on a mac at the moment so have to use GNUStep and ObjC 1.0 therefore not tested:

//======================================
// Delegate Test
//
// Understanding the functionality and 
// use of Objective C delegates.
//======================================
#import <stdio.h>
#import <Foundation/NSObject.h>
//--------------------------------------
// Test Class - Main Delegate
//
// Implements based on events received
// from main controller.
//--------------------------------------
@interface MainDelegate : NSObject
{
//No Members
}
-(void) onButtonPress;
-(void) onAddToList;
@end
@implementation MainDelegate
-(void) onButtonPress
{
	printf("Do Button Stuff\n");
}
-(void) onAddToList
{
	printf("Do Stuff With New List Object\n");
}
@end
//--------------------------------------
// Test Class - Main Controller
//
// This class will act as the main
// controller which will invoke the
// delegate class.
//--------------------------------------
@class AppController;  //Forward Declaration
//Register the delegate methods with this class
@protocol OurDelegate
@required	//These delegate method must exist (if you use opitonal then we must check they exist first)
-(void) onButtonPress;
-(void) onAddToList;
@end
@interface AppController : NSObject
{
	id <OurDelegate> mpDelegate;
}
-(void) ButtonPress;
-(void) AddToList;
@property (nonatomic, assign) id <OurDelegate> mpDelegate; //Don't Retain the delegate it doesn't belong to us
@end
@implementation AppController
@synthesize mpDelegate;
-(void) ButtonPress
{
	printf("EVENT - Button Pressed\n");
	[[self mpDelegate] onButtonPress];
}
-(void) AddToList
{
	printf("EVENT - Add To List\n");
	[[self mpDelegate] onAddToList];
}
@end
int main()
{
	//Create an instance of our delagatee that (skeleton) handles events
	AppController* pMainCtrl = [AppController alloc];
	//Now create our delegate that actually interprets events and fires some code
	MainDelegate* pDelegate = [MainDelegate alloc];
	//Set the delegate
	pMainCtrl.mpDelegate = pDelegate;
	//Fake a button press
	[pMainCtrl ButtonPress];
	//Fake another function call
	[pMainCtrl AddToList];
	
	//Free up memory
	[pMainCtrl release];
	pMainCtrl = nil;
	
	return 0;
}

Enter Tag

2009-10-08T15:01:00.001-07:00

Started at tag-games this morning for my first day in the games industry! Went pretty well I now have a company e-mail address which is awesome. Now its about coming to terms with the iPhone and Macs. Lovely…

I guess the demo work will be on hold for a while but I’ll get back to it soon.

Deferred Shadow Maps

2009-09-27T16:08:00.001-07:00

Now that I have my deferred renderer up and running I thought I would add shadow mapping to the framework as they seem to go hand in hand. However when I got down to implementing them I didn’t really know where to start. Obviously with standard shadow mapping techniques you do one pass to obtain the scene depth from the light source and then the second pass calculates the occlusion factor.

However I had some weird notion that with deferred shading I wouldn’t need to render the geometry twice (or it seems to me that should be the case). Yet I saw a couple of articles that are titled deferred shadow maps that actually perform the depth calculation in a separate shader and render to a separate depth buffer. What’s different about that? Surely both depths could be obtained at the same time at very least and save two geometry passes? However this would mean calculating and storing the light depth in the G-Buffer along with the Z-depth. The problem is that the render target for the Z-depth is a 128-bit single; this means that the light depth would also require a 128-bit buffer. I wonder if both depth buffers need to be so precise and that way the two depth maps could be stored in a single buffer. I’ll try a bit more research failing that I’ll give it a bash and see what happens. After this I think I might leave this lighting side of graphics for a while and think about doing some volumetric data stuff…or I might finally get round to doing light scattering rendering my last null and void.

On the plus side I discovered the beauty of Windows Live Writer! It’s pretty ace and the plug-ins are the cats pyjamas; hence the new found source tags. I shall no longer need to arse around with google docs to get source code up as I can link straight to Skydrive or automatically add solutions or binaries as downloads. Why has nobody told me!

Deferred Shading

2009-09-25T08:27:00.000-07:00

I've got the bare bones of my deferred shading framework up and running. At the moment the world-space normals, linear depth, diffuse colour and specular value are output to the G-Buffer in 128-bit targets (maybe a bit much but I'm only testing). Using this data the directional lighting, point lighting and SSAO can be calculated in screen space as a post process then combined to create the final scene. It was actually really easy to set-up and I love the way that SSAO integrates. Obviously one of the advantages of deferred lighting is that it is easier to manage multiple lights and this is independent of scene complexity. However I can't get my multiple lights to work yet. In a similar way to the SSAO and Shadow Maps; the lighting shaders render a light map to a separate render target (i.e. a render target for point and one for directional (stupid set-up at the moment ideally these will become one light map)). However the way I am trying to accomplish multiple light sources is by rendering to a target then performing multiple passes of the light shader additively blending the fullscreen quads; before I reset rendering to the frame-buffer.

1:     //Create the point light map
2:     mPointLightFX.BeginRenderToLightMap();
3: 
4:     //Initialise Light 1 - Blue
5:     mPointLightFX.SetLightCol(D3DXVECTOR3(0.0f, 0.0f, 1.0f));
6:     mPointLightFX.SetLightPos(D3DXVECTOR3(0.0f, 100.0f, 20.0f));
7:     mPointLightFX.RenderFullscreenQuad();
8: 
9:     //Initialise Light 2 - Red
10:     mPointLightFX.SetLightCol(D3DXVECTOR3(1.0f, 0.0f, 0.0f));
11:     mPointLightFX.SetLightPos(D3DXVECTOR3(20.0f, 100.0f, 0.0f));
12:     mPointLightFX.RenderFullscreenQuad();
13: 
14:     mPointLightFX.EndRenderToLightMap();
15: 
16:     //Reset Rendering Back to the Frame-Buffer
17:     ResetRenderTargets();

This results in only the final light being rendered but I'll keep plugging away.

EDIT –Solved

Stupid, stupid b*&@£rd. Forgot to update the shader variables after I reset the light colour. So the blending works fine.

Screen-Space Ambient Cel Shading

2009-09-14T16:57:00.000-07:00

Well I finally got round to doing my SSAO shader. Had a bit of trouble initially with some of the documentation as it wasn't always clear what space things should be done in. For instance the normals should be in view space but I had them in world space. Unfortunately this resulted in my SSAO looking like the toon shader it set out not to be...The effects were pretty cool and really simple to add as it is just matter of finding the dot product between the sampled normal and the world space normal of the pixel; and multiplying this difference into the final occlusion. Once I realised my space mistake, it was just a matter of tweaking the radius of the hemisphere and the contrast etc in order to get the desired result. The final shader is still not quite there yet (I have a post of it on my codefolio); but I'll keep adjusting it till I'm happy....then deferred shading!

Oh Pretty

2009-09-10T08:31:00.000-07:00

Decided to add another couple of pieces to my portfolio this week, so I thought I would look at a couple of graphics techniques I never got round to using at uni. Firstly I implemented Parallax Occlusion Mapping. It actually wasn't to bad to code, the fact that it only requires one pass made it alot easier. I did only use the linear interpolated technique but I'll probably get round to adding the Nvidia cone stepping method. The results are pretty nice so I am more than happy with that.

The other technique I am in the process of implementing is Screen-Space Ambient Occlusion. I already know a fair whack about AO, enough to know that the Nvida SSAO method is comparitively slow; but there is alot of documentation about it etc. Normal map, depth map...blah...blah. Looking through GameDev etc it seems alot of people use AO algorithms that act more like edge detection, almost like a cel shader, so I hope to avoid doing that. Anyhow I'll cut to the chase I wanted to load a high poly model in (stanford dragon cliche) but until now I have only been working with my own DX10 model loader not .x. I love DX10 but the lack of model loader is balls! So I thought I would just use DXUT but the bloody thing needs to be compiled in unicode. This means I have to go through my framework changing all the bloody strings! Plus the documentation on the MSDN website is wrong! There is no CDXUTMesh10 but there is a CDXUTSDKMesh that only loads .sdkmesh files.

Seriously I wish Microsoft would provide a .x mesh loader. I know a lot of studios use their own formats but for us without the benefit of a dev team and in-house libraries .x meshes are staple DirectX. All my DX9 projects use .x meshes and now I have to use DXUT! It feels almost dirty; like using GLUT instead of plain OpenGL...

EDIT:
DXUT for the win. (I'll post the HLSL code on my portfolio when finished)

A New Objective

2009-09-07T03:51:00.000-07:00

The interview at Rockstar was pretty awful; I panicked and absolutely bombed the programming test. Anyhow...I had another interview at Tag Games last week that I am more hopeful about. Therefore in anticipation that I might be offered the job I am looking at Objective C. Unfortunately (wait) fortunately I don't own a Mac, so I had to download GNUstep so I could use the gcc compiler for Windows. Compiling is no bother once you create a makefile that links the global libraries.

File: GNUmakefile

include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = ToolName
ToolName_OBJC_FILES = Source.m
include $(GNUSTEP_MAKEFILES)/tool.make

I know a few people who use Objective C and I don't know anyone who likes it. Its kind of a bastardized version of C and SmallTalk. Personally if I was developing for the iPhone I would have a Objective C wrapper and do all the coding in C++.

Classes:

Class definitions are slightly different that C++ but are ok. However the way methods are declared is erm not for me. Multiple parameters, for instance, is really unintuitive if your used to C or Java. Default access is protected instead of private. Oh and you use #import instead of #include. This has the benefit of only compiling the file once (like #pragma once or #ifndef etc). Some other quirks before we move on, bool is yes or no, self is like this, nil is null, everything is a pointer, files are declared .m and '+' indicates a class method like +alloc, wheras a '-' indicates an instance method like -(void) print.

  1: //----------------------------------
  2: // Definition
  3: //----------------------------------
  4: #import
  5: 
  6: @interface CMyClass : CBase 
  7: {
  8: @private
  9: float mfFloat1;
 10: float mfFloat2;
 11: int mInt;
 12: }
 13: //Constructor
 14: -(CMyClass *) InitWithInt : (int) dInt; 
 15: 
 16: //Declare methods outside the braces
 17: -(void) SetInt : (int) fInt;
 18: -(void) SetFloat1 : (float) fFloat1 SetFloat2 : (float) fFloat2;
 19: -(int) GetInt;
 20: -(void) Print;
 21: @end
 22: 
 23: //----------------------------------
 24: // Declaration
 25: //----------------------------------
 26: @implementation CMyClass
 27: //---------------------------
 28: // Constructor
 29: //---------------------------
 30: -(CMyClass*) InitWithInt : (int) dInt
 31: {
 32: //Self is a bit like this
 33: //init is like a default constructor
 34: //super accesses the base constructor for inheritance.
 35: self = [super init];
 36: if(self)
 37: {
 38: [self SetInt : dInt];
 39: }
 40: 
 41: return self; 
 42: }
 43: //----------------------
 44: // Set Int
 45: //----------------------
 46: -(void) SetInt : (int) dInt
 47: {
 48: mInt = dInt;
 49: }
 50: //-----------------------
 51: // Set Float1 and Float2
 52: //-----------------------
 53: -(void) SetFloat1 : (float) fFloat1 SetFloat2 : (float) fFloat2
 54: {
 55: mfFloat1 = fFloat1;
 56: mfFloat2 = fFloat2;
 57: }
 58: //-----------------------
 59: // Get Int
 60: //-----------------------
 61: -(int) GetInt
 62: {
 63: return mInt;
 64: }
 65: //-----------------------
 66: // Print
 67: //-----------------------
 68: -(void) Print
 69: {
 70: printf(%d, %f, %f \n", mInt, mfFloat1, mffloat2);
 71: }
 72: @end
 73: //=============================================
 74: // Main
 75: //=============================================
 76: int main() 
 77: {
 78: //Allocate memory for class then construct it using init 
 79: CMyClass* pInst1 = [[CMyClass alloc]init];
 80: //Allocate memory but construct with our new constructor
 81: CMyClass* pInst2 = [[CMyClassalloc] InitWithInt : 1];
 82: 
 83: //Call methods
 84: [pInst1 SetInt : 5];
 85: [pInst1 SetFloat1 : 1.0f SetFloat2 : 2.0f];
 86: [pInst1 Print];
 87: 
 88: [pInst2 SetFloat1 : 1.0f SetFloat2 : 2.0f];
 89: [pInst2 Print];
 90: 
 91: //Free class memory
 92: [pInst1 release];
 93: [pInst2 release];
 94: 
 95: return 0;
 96: }
 97:

This simple class has some accessors and a print method. The SetFloat method takes two arguments; fFloat1 and fFloat2; it just looks weird. Objective C works as everything is a message. In order for classes to handle each others messages most of them inherit from NSObject class. The benefits of objective C are that it is dynamically typed using the id keyword (almost like a void*). Also classes can be loaded only at runtime when required which lowers memory costs; more suited to the iPhone etc.

The language has other strangeness like categories and posing, yet as it is a subset of C it does not allow multiple inheritance but ultimately who cares. Really if it wasn't for the bloody iPhone and Apple's insistence on bringing back a language used in their OS that everyone thought had died a horrible death then no-one would need to look at it's ridiculous syntax ever again.

Hey Hey I Wanna Be A Rockstar

2009-08-28T06:34:00.000-07:00

Just as depression was about to kick in about my lack of job; I have an interview for a graphics programming position at Rockstar North. It couldn't come a minute too soon; with any luck they will snap me up and use all my free time so I don't have to bother working on my engine for the foreseeable future!

The engine seemed like a good idea and to be honest it isn't going too badly but incorporating the WinSock wrapper this early was a mistake. Mainly because the physics isn't finished and testing it is causing my bowels to cry. What really kick started it though was when I was asked if the maths libraries incorporated SIMD. So guess what...now the maths libraries have to be updated.

I also have to rework the collision reaction for the physics engine; as objects that hit surfaces at an angle will continue to increase in velocity until they have left the screen, shot through the frame buffer and out the wall.

Summing Up and Future Posts

2009-05-13T12:12:00.000-07:00

I am almost finished the dissertation, I am at the stage of analyzing my results and drawing conclusions. However I feel it is important to include them here aswell.

Graphics programming is heading in the direction of do everything on the GPU. This is highlighted by the removal of the fixed functionality from DirectX 10; this is what prompted me to do this project. Procedural terrain is something that I enjoy and I feel can be incorporated into games. I wanted to know if a procedural planet could be created entirely on the GPU and if it was of the same quality as modern CPU generated planets. The project has been a success and has shown me that it is possible, however the bigger conclusion is that the project sits at a crossroads. DirectX 10 has no fixed functionality therefore the CPU planet tessellation is non existant due to the lack of immediate rendering, however the GPU can tessellate the planet but decreasing LOD is inefficient, it cna only be achieved in the GS by replacing the mesh with the base mesh and subdividing to get the required detail. This does reduce poly count but I am not sure the performance hit is worthwhile. Therefore the CPU is best for tessellation but rendering can only be done on the GPU, passing all the vertices to the shader is slow. Unfortunately for this project but lucky for future work, DirectX 11 allows, not only a primitve to be passed to the shader, but entire meshes, using the Hull shader. This would allow for an LOD that could combine triangles.

To sum up I feel that the GPU approach is the way forward, however perhaps the structure is not there at the moment to allow for incorporation of procedural planets in game, solely using the GPU.

The posts have been erratic. Therefore I am going to post a step by step tutorial of how I the implementation.

Final GPU Planet

2009-05-01T10:24:00.000-07:00

The GPU...Not All It's Cracked Up To Be

2009-04-26T14:02:00.000-07:00

I am so close to finishing but as alway a few problems are persisting. Most notably the cracks that appear in the GPU LOD, as demonstrated by the video above. I am not sure why, but I am not above handing it like that as deadline is looming! The writing is going well, the dissertation is starting to take shape. The faceted lighting isn't great but unfortunately its too late in the day to start using adjacency buffers.

Optimisation

2009-04-20T08:55:00.000-07:00

I have been working on optimising my program this week, using the VS 2005 profiler and Nvidia PerfHUD. This is mainly because there is a fair bit of load time involved in the project that I am trying to reduce. I have also been tweaking textures and terrain features. The one thing I really need to put in place is VSync. The camera can become jerky once triangles start to split but this is because the framerate falls from 2000+ to 500+. If I can cap it at 60fps then everything should be smooth.

EDIT: It turns out it was incredibly easy to VSync the application It was simply a case of setting a flag at the call to swapchain::present(SyncInterval, Param2), changing sync interval from zero to 1 to VSync to 60 fps.

The Home Straight

2009-04-14T02:57:00.000-07:00

I have been busy the last few weeks tidying up and fixing my project. I only have a few things left to do on the programming side. The most important (and annoying) of which are fixing the normals on the CPU planet. I rendered it without lighting and it looks fine, however the problem is that the normals seem to alternate. I still have to tweak the texturing and vertex displacement to get the best look, then I am done.

This week I have implemented an algorithm on the CPU and GPU that tests whether a vertex is within the FOV, this allows for culling of rendering and calculations.I never managed to find out a way to scale the planet down and manipulate the projection matrix, so I will just have to stick with the large numbers. I manged to get the texture splatting in, using fractals as a rgb blendmap.

I have mostly been working on my literature review, by far and away the hardest part of the dissertation.

Looking At Things From A Different Perspective

2009-03-29T08:04:00.000-07:00

I have literally stopped mid-programming because I am fed up with the huge numbers and z-buffer issues that happen when I scaled my planet up. The radius of the Earth is over 6000 km, and Earth is only a small to medium sized planet. At the moment I have the planet radius set to 10,000 but this is metres in order to scale the planet up by ten times the far clipping plane will need to be set at 300,000 to 500,000. This throws the z-buffer out aswell and causes weird clipping issues.

So I am going to try something different. Really its a matter of scale. If i can alter the viewing perspective so that everything seems larger than it is then I can use smaller numbers which will be more efficient and won't break depth sorting. The problem is I am not sure how to do this.

More research required :(

Split Decisions

2009-03-28T08:40:00.000-07:00

Making good progress this week and I am not so worried about getting it finished. Have just been working on the methodology section of my dissertation and added some base knowledge to my introduction section i.e. some background on the techniques I have used. Anyway back onto coding...

I have switched back to the CPU implementation today and I have two task before I can but this bet to bed. Firstly I really want to fix my normal problem. It seems that as soon as I create new faces for the mesh the normals are wrong. It's not even random its a pattern of wrong normals. I don't understand why as I generate the normal for a triangle after I split it but before I push it onto the list. Its just as simple cross product of two vertex positions and it seems to work for some and not others. The second task is to re-write the LOD driving algorithm i.e. deciding when to split and combine. The method I am using is awful and slow. So I am reading about another method that uses an error metric on top of the distance based calculation I am using. Bare with me as I am just going to do a brain dump here based on what I am reading at the moment...

The new method uses distance, scale and the error limit.
Distance - The length of the vector between the point in question (in my case the midpoint of the base side of a triangle) and the camera position.
Error Metric - This seems to be some arbitrary error value determined by trial and error (no pun intended).

A ratio is then determined of error over distance. If this ratio is greater than the limit value provided the split. So whats this limit value...apparently its also a arbitrary number.

Areas with low poly counts will have a low error metric and not be split, however areas close to the camera or that have high poly count will be split. A scale value can be introduced to scale the error. A large scale value will favour splitting rough terrain a small scale value will be weight toward distance.

Right I'll implement this and post the results.

EDIT:

This method seemed to work a lot better. I had to add an error metric to my LOD triangle struct. The original metric was 100 and each child had half the error metric. Although I may tweak this. The lower the error metric the less likely it is to be split. I could alter the error metric of each trinagle based on its displacement factor so that flat land is not split but mountains are.

Also I have fixed my vertex displacement in the GPU it was my noise function. I wasnt clamping the values properly. So now I have to implement per pixel lighting in the GS.

Trying to make your planet not look like a dead puffer fish

2009-03-27T08:59:00.000-07:00

Now that I have got a suitably detailed sphere; I am working on creating the landscape features. In theory this should have been quite easy; but as usual...

I have already implemented several noise beased fractal functions in HLSL. The base noise function is 3D Simplex noise (a shader style noise function by the master of noisiness himself Mr Perlin). With this in place I needed to pass in a base noise texture, simply a 256x256 texture filled with random noise for the SImplex noise to sample. I have come up with some really interesting looks and have been tewaking values most of the day; however there has been some problems.

The first problem is really what shader to do the vertex displacement in? Well I thought that it would be easier to sample the displacement map in the render vertex shader (i.e after the GS has tessellated the mesh) but the problem here is calculating the normals! Scrap that idea, I thought that I would the perform the displacement in the GS but this produced huge gaps and holes in the geometry....back to the VS. I then discovered a paper thet Ken Perlin did for Nvidia about calculating normals from noise functions. Basically he suggests approximating the derivative of the function by adding a fractional amount to each component of the position vector, in turn (i.e x + 0.0001, y, z). Then subtracting these new noise values from original noise to give a vector which is then subtracted from the original normal and normalized to give the new normal. I ralise that made little sense...

float e = 0.000001;
float ScaleFactor = 8;

float Noise = RidgedMultiFractal(vIn.PosL, vIn.Norm, NoiseTex, 0.1, 4.5) * ScaleFactor;
float Noisex = RidgedMultiFractal(float3(vIn.PosL.x + e, vIn.PosL.y, vIn.PosL.z), vIn.Norm, NoiseTex, 0.1, 4.5) * ScaleFactor;
float Noisey = RidgedMultiFractal(float3(vIn.PosL.x, vIn.PosL.y + e, vIn.PosL.z), vIn.Norm, NoiseTex, 0.1, 4.5) * ScaleFactor;
float Noisez = RidgedMultiFractal(float3(vIn.PosL.x, vIn.PosL.y, vIn.PosL.z + e), vIn.Norm, NoiseTex, 0.1, 4.5) * ScaleFactor;

float3 dF = float3((Noisex - Noise), (Noisey - Noise), (Noisez - Noise))/e;
vIn.Norm = normalize(vIn.Norm - dF);

Anyway it still doesn't look quite right so this is my focus for next week!

Me 1 - GS 0

2009-03-25T09:24:00.000-07:00

Just this very minute I have conquered the GS tessellation issue. In all honestly I am still not sure why it works now when the implementation I had originally was better. Theoretically I should simply Draw using the split shader and the initial VB and from that pass on use the stream out buffer as my input as opposed to the initial VB. I have been doing this with no success but now it seems by drawing with the initial VB then with stream out produces results.

switch(RenderType)
{
case 0: //Render with the Draw Shader using Pre-built VB data

//Draw with pre-built vertices
mDevice->IASetVertexBuffers(0, 1, &mVB, &Stride, &Offset);
mDevice->SOSetTargets(1, &mStreamBuff, &Offset);
mDevice->Draw(miNumVerts, 0);
//Unbind the buffer from stream out so we can draw
mDevice->SOSetTargets(1, BlankBuff, &Offset);
mDevice->IASetVertexBuffers(0, 1, &mDrawBuff, &Stride, &Offset);
//Swap the buffers
std::swap(mDrawBuff, mStreamBuff);
break;

case 1: //Use the LOD shader to tessellate the mesh

for(int i =0; i<4;>
mDevice->IASetVertexBuffers(0, 1, &mDrawBuff, &Stride, &Offset);
//Updated vertices are streamed to here
mDevice->SOSetTargets(1, &mStreamBuff, &Offset);
//From now on use the verts created by the GS, pass these back in for recursion
mDevice->DrawAuto();
//Unbind the buffer from stream out so we can draw
mDevice->SOSetTargets(1, BlankBuff, &Offset);
//Swap the buffers
std::swap(mDrawBuff, mStreamBuff);
}
break;

case 2:
//Use the LOD shader to tessellate the mesh
mDevice->IASetVertexBuffers(0, 1, &mDrawBuff, &Stride, &Offset);
//From now on use the verts created by the GS, pass these back in for recursion
mDevice->DrawAuto();
break;
}

Ideally I was doing case 1 once, thencase 2 for the desired number of splits then case 3. However now I have to do case 1 for the number of splits too.

So here are a few screenshots:

Texture Blending - Behold the glory

2009-03-22T16:37:00.000-07:00

Everything seems to be heading along nicely this week with the exception of the stream out! I have debugged the shader using PIX and queried the pipeline during runtime. The result is that the GS is functioning properly and is streaming to the correct buffer. The problem is that the PS is not being 'invoked' still I will persist. In the meantime I have been tweaking the blend factors for my textures; here's some snippets:

Sometimes things just work

2009-03-20T05:43:00.000-07:00

I really don't know what happened yesterday; after I posted that blog I managed to fix my CPU LOD tessellation algorithm. I have been staring at the code for weeks but I finally realised that I had transposed the vertices of the new child nodes (i.e. child 1 had positions 0, 1, 2 instead of 2, 0,1 etc...). Then I implemented bump mapping and it looks awesome. So today I am determined to fix that stream out problem!

Here is a screenshot of the CPU mesh tessellation. I have inverted some of the normals to make it easier to see.

Life is but a stream…

2009-03-19T08:30:00.001-07:00

I feel that my posts have become a bit erratic so I am taking the time to sum up what I have done so far and what I have left to do; to focus myself as much as anything. Here goes…

I have been working simultaneously on GPU and CPU implementation the Split/Combine algorithm has been implemented on the CPU using midpoint subdivision. However there are a few problems to be solved as we get a bit of Z-fighting. The split algorithm on the GPU has been coded, which uses a similar algorithm to the CPU one; however this technique makes use of the GeoShader. The one aspect of this that is causing problems is the stream-out stage, this is what I am currently working on.

In order to recursively tessellate the mesh the output mesh must then become the input for the nest pass. This is achieved by using stream out to output vertex data to stream VB. This VB is then copied into a Draw VB which is the input for the next pass. The initial platonic shape is held in a separate Init VB, this is only passed to the shader pipeline once. The problem arises when trying to cap the number of recursions; once the mesh has been split sufficiently it must then be rendered without the GS stage. At the moment I have a counter that performs the above tessellation; once the counter reaches zero the final mesh data taken from Draw VB is used in a different shader pass which has no GS. The final stage is creating a blank screen but I think I know what the problem is. Once this is fixed I will have a scaling planet based on the camera distance from a polygon.

Moving on from LOD; I have also had a lot of success in recent weeks with procedural texturing. It has been difficult identifying the best methods; but this is what I am doing…

Creating noise on the shader can take up a huge amount of the instruction set, so I create noise textures on the CPU at load time, using fBm and pass them and the landscape textures in as texture arrays. I then choose the landscape texture to use based on altitude and angle of incline (angle between face normal and up vector). I sample this texture by summing the various noise textures, halving the texture coords each time, and using the components of noise as blend weights. I also multiply in the noise value to dissipate texture repetition. There is huge scope for playing around with all these values, it will be hard to select the best method until the planet is fully scaled. The LOD of the texture is adjusted by doubling and splitting the tex coords based on distance from the world.

The final stage is displacing the mesh. This will be achieved on the CPU by altering the vertex pos using a mixture of fBm and multi-fractals and on the GPU by sampling the noise as a height map.

If I have time (fingers crossed), I will implement bump mapping to improve realism, create an atmosphere/sky and add a water sphere (maybe just a simple planet within the planet acting as a water table.

Life’s Better When It’s Noisy

2009-03-17T02:12:00.001-07:00

This week I have focused on two goals. Firstly I adapted my GeoShader to stream out to a vertex buffer; in order to perform recursive subdivision. This involves creating an additional two vertex buffers and reading into them alternately by swapping them every frame. I seem to be getting a blank screen at the moment so I will need to double check that. The second aspect I am working on is the procedural texturing. I am so close to completing this step, but at the moment the textures are not right. I have researched the best way to implement noise in the shader and it seems that creating a base noise texture and passing that in is the most efficient way. Luckily this is easy to do in directx, as I simply fill an array with perlin noise samples and then create a texture using the D3D device. So I am almost back up to date with my Gantt chart.

Progress Report

2009-03-10T13:13:00.001-07:00

Just a quick update on my progress. Although the Gantt chart suggests otherwise I feel that I am maybe a week behind. I think the original chart was ambitious and I left myself overlap time at the end. The few problems that I have left to solve are the CPU splitting function which causes distortion, porting perlin noise into the shader and performing multiple passes of the GS. The GS tessellation works well for one pass but I now need to stream it out to a new buffer. I have finally made a breakthrough with the procedural texturing and once the noise function has been implemented in the effect file, the texturing will be complete.

In relation to the actual dissertation; I have finished the introduction and abstract (with the exception of the results) and have began both methodology sections. I intend to format the document correctly this week and finish the literature review.

Still confident that I can do it!

Saved by a Black Knight!

2009-03-03T09:10:00.001-08:00

I would like to thank Black Knight and Evil Steve on the Gamedev.net forums, who have finally helped me identify my memory problem! 2 weeks of creating copy constructors and copy assignments and the problem was simply that I was pointing to a local variable, which would only be stored on the stack and become invalid once the function returned. On the plus side my program has no memory leaks as I went through it with a fine tooth comb…or a memory manager as it is also known and made sure everything was allocated and released properly. My LOD algorithm is tessellating my planet properly, however there are a few cracks in the mesh, which I will attempt to solve next.

Memory Hates Me. Part II

2009-02-27T04:08:00.001-08:00

The problem from last post is still there. I have tried several solutions to solve it, but like Edison I have found lots of ways not to solve my problem. Firstly I tried reserving a memory size for my stl vector. This would prevent it jumping around in memory. Secondly I tried using a copy constructor for my triangle struct which would enable me to make a deep copy of the struct data, but once again this failed. Then I discovered that allocating any memory, either using new or push_back would cause the list pointers to become bad. It seems to me that I may have a memory leak so I will use Visual Studio to track all my new and delete calls.

On a better note I finished my Fractals class and ported a version of it into an effects file to be used as a shader by the GPU. So progress this week has not been too bad.

Memory Hates Me

2009-02-23T09:25:00.001-08:00

I am having a really big problem this week that is drastically slowing down progress. The problem is a result of memory bashing; but not in a way I have experienced before. Whenever triangle data needs to be obtained from the list a pointer is returned to that triangle. However as mentioned before the vertex buffer only handles arrays, so the vertex data must be taken from each triangle and added to a dynamic vector array. Vectors allocate contiguous blocks of memory and as a result will jump about in memory. Therefore a vector will always take data by value and not reference. I am copying the triangle data into a temporary struct and then push that onto the back of the vector.

pTri = List(i);

VertexStruct.Pos = pTri->Pos[j]

vector.push_back(VertexStruct);

The above code copies the data into the struct correctly and pushes it onto the vector correctly. However the push_back call corrupts the triangle list. It seems that the vector is expanding in memory and overwriting the list. Or that the data is not being copied and therefore when the vector moves the data in memory the pointer is no longer valid. I am going to try and memcpy the data and see if that solves the problem

Put One In and Get Four Out. You Do The Hokey Cokey...

2009-02-17T03:25:00.000-08:00

This week I have been learning about Geometry shaders and they seem to be a lot easier to use than I anticipated. I have not measured the difference between LOD on the CPU and GPU yet but for effeciency of coding the GS wins, hands down. Splitting a triangle on the CPU involves setting up pointers to edges, maintaining a list of diamonds etc; it is much easier on the GPU.

To setup the GS you must first decide what primitive will be passed in, i.e a line, quad etc; in this case three vertices are input for a triangle. A max vertex count is set to limit the number of vertices that can be output. The midpoint of each line is calculated and these are appended to an output stream. This stream is then passed into the pixel shader. Job done.

Slight Adjustment…

2009-02-12T04:10:00.001-08:00

Following the last post, where I was struggling to identify a way to find a relationship between neighbour triangles and array positions, I have had to perform a slight overhaul. Previously the triangles were stored in a vector array, as vertex buffers only handle arrays; however in order to insert new triangles into the mesh I have had to write my own linked list class and I am in the process of converting from vector array to linked list. This allows me to insert and delete arbitrary nodes. The downside is that now I must copy the vertex data from the list into a vector array before rendering.

Luckily I can simultaneously begin work on texturing. I think this is the most complex part of the project. I have created a perlin noise class and from this I will be able to implement fBm. I am not sure of the best way to texture the mesh. One way would be to have grass, snow and earth textures and use the noise to sample them differently. However there are some articles which create colour tables in the pixel shaders and sample them across the polygon. I have found that none of the articles are particularly clear on how to begin. Even the book “Texturing and Modelling: A Procedural Approach” does not give a good indication of how to begin, of course it doesn’t help that all the code is written for RenderMan!

Relationship Breakdown

2009-02-09T12:01:00.000-08:00

This week I have pretty much finished the split and merge aspect of the LOD algorithm. The methods work in debugging but the problem is that I need to come up with a method to insert the triangles into the vertex array. The main principle behind splitting is that a triangle is passed in and from this we can get the opposite triangle from its edge 2 pointer. The original triangle and opposite triangle are used to create the new children. These children are then inserted into the array in the cell after their parents. The problem is how do I get the array position of the opposite triangle? One option is to store the element number in each triangle struct, however whenever a new triangle is created I would have to update all the triangles following this in the array. That could be a lot of triangles if the new polygon has to be inserted at element 2. I will investigate other solutions and hopefully have one in place in the next few days then the LOD will be complete. I am hoping there will be asimple relationship between the triangle and it's opposite in terms of array position.

The next implementation stage will be to determine which triangles need to be split and merged based on the cameras field of view.

In terms of dissertation writing I am starting the introduction tonight, and following last weeks lecture; beginning the literature review. I have a good idea of what I intend to write so it should be straightforward. It's a small step to getting this project bound!

Ladies & Gentlemen; Behold...In Glorius Technicolour!

2009-02-05T11:53:00.000-08:00

Just thought I would post a picture of my progress. I was having a few matrix problems but now the rendering aspect is fixed and behold:

Each vertex has been given a colour to highlight the structure of the mesh. The mesh is an icosahedron made up of 20 polygons.

Most of the LOD algorithm is in but this minor success has boosted my motivation, so progress will hopefully be thick and fast now!

God created the Earth in 7 days....He never used LOD!

2009-02-03T16:27:00.000-08:00

(Or does the Earth only appear when you are looking at it?)

I am just posting a quick update about my work this week. Finally solved that problem relating to drawing the primitives, the solution was basically that instead of pointing the VBO to the memory address of the vertex list, instead I had to point it to the address of the first element. Took me ages to work that one out and the internet was little use as everyone else seems to use a vertex array. However I think a list allows the mesh to be more dynamic.

I am still implementing the altered ROAM algorithm, however I am debating whether to split the LOD class into multiple classes as a 'diamond' often points to itself and there are several functions involved in determining whether or not a polygon is in a diamond and in creating the 'diamond' itself.

At the same time I am also working on the basic shell of the other procedural classes in the framework. I have created a wrapper to handle the displacement techniques which only allow the user to access the perlin noise and fractal class through that.

Finally I have been reading ways to prioritise the triangles in the mesh to identify which ones to split or merge. This will be the next stage of implementation, which will hopefully only take a few days now that I can actually see something on screen!

This may mean I can actually post pictures again!

ROAM? I'd Rather Take a Hike!

2009-01-27T05:50:00.000-08:00

This week work has begun on my LOD algorithm. I am using Andrew True's optimized ROAM method as a guideline, outlined in his Gamedev article "Procedural Planets Part 1". One of the stipulations of the ROAM algorithm, for use on a spherical surface, is that the base shape must be a seamless primitive constructed from triangles. The simplest shape to begin with is a cube; however a more complex geo-spherical shape will reduce the number of recursions required to create the planet, therefore the best base shape to use is an icosahedron. The Planet wrapper class constructs the geo-sphere mesh and adds the vertices to a VB to be rendered.

The LOD class is responsible for splitting and combining triangles, updating the pointers to neighbours, children and parents and also maintaining the pointers to the other triangles making up the diamond shape to which a triangle belongs. The rules of ROAMing state that a triangle can only be merged if it is in the diamond step, therefore in order to optimize performance it is beneficial to keep track of all the diamonds at the current LOD.

The problem with ROAM and other similar methods is that there are pointers to absolutely everything! It can be hard to track exaclty how one polygon relates to its neighbours. Every time the mesh changes, the neighbours of each triangle have to be identified, its children have to be linked and their parent pointer must be set. Finally if the triangle was part of a diamond before it split, that diamond does not exist anymore so it must be deleted and a new diamond calculated!

I have not quite decided the best route to take in terms of optimizing the way in which the mesh is stored. I think the next stage after creating the LOD algorithm is to split the planet using a quadtree and assign each quadrant a vertex buffer. Processing VBO's in batches allows us to change a small number of vertices without recalculating a large buffer that holds every vertex in the mesh.

One thing that I have identified for all the geologists in the world...if you want to know what is at the centre of our planet there's a good chance its a linked list!

Buffer My Vertices

2009-01-21T08:07:00.000-08:00

Just a quick update on the framework for my project. Finally managed to get rid of the linking errors by painstakingly going through the properties and checking all the libraries. The framework is practically finished and I have started working on the level of detail algorithm.

I am just implementing the vertex buffer to hold the vertices of the world mesh. VBO's are handled differently in DirectX 10. Unlike DX 9, there is no need to declare a specific vertex buffer; instead you declare a generic buffer and set whether it is an index or vertex buffer. For this project the best route to take it to use dynamic buffers, as Nvidia say their chipset improves effeciency by 70% over static buffers. Dynamic buffers are better suited as the mesh vertices will alter frequently. DirectX 10 allows the developer to set how the buffers are accessed i.e. whether the CPU can write and read from them or just the GPU.

The problem is that the vertices of each triangle are held in an struct, conatining the positon vectors of the 3 points, and pointers to the polygons neighbours, children and parent. The vertex buffer will only store coordinates in a contiguous fashion. Therefore the actual vertices need to be stored in a list and copied into the buffer.

Hopefully I will have a triangle on screen by the end of the week. Then I will work out splitting the triangles along their midpoint to create a new polygon. This will allow me to test the function befre I concern myself with deciding which triangles to split.

Stop Press. Framework update

2009-01-18T10:58:00.000-08:00

So far the framework is causing a few problems, I have setup my direct 3d manager and my game class. The camera class has also been created; however I am getting linking errors with regard to the D3DX10 functions. I have trawled through the forums and it seems to be a problem with respect to 64 bit libraries but I'm not much closer to fixing it.

With any luck I will be hit by divine inspiration...until then CTRL + F5!

DirectX 10 - Framework

2009-01-08T16:57:00.000-08:00

I have recently been working on my new framework for the project. Originally I had planned to complete the demo using OpenGL, however now that I intend to make use of geometry shaders this calls for DirectX 10.

Having never used DX10 before this made my Christmas rather eventful. Even initialising a Direct3D window is quite different in DX10 than 9. In 9 you really just have to set up a window and a device manager. With 10 a swap chain has to be created to allow buffer switching. This is just one of the few differences.

Currently I have a Direct3D class from which the 'game' glass is inherited. The camera class has been setup to incorporate a first person camera. The next stage is to incorporate a base shader class. Effects are handles slightly differently in DirectX 10 as they are handled by the manager. I have begun implementing this class which will allow me to include the geometry shader code.

Im currently focusing on the reading about geometry shaders although there seems to be a lack of coherent material with regard to DX10. The most common publications tend to be over simplified and very messy. I hope to finish the framework wihtin the next 2-3 weeks this will allow me to start creating the planet on the CPU.

Oh When the Cubes Go Marching In...

2008-11-13T12:03:00.000-08:00

I have found another technique for rendering terrain on the geometry shader that can create dramatically more complex terrain features, such as overhangs and caves. Terrain has traditionally been computed as a heightmap, calculated on the CPU, however it is impossible to create the above effects using this method.

The way to achieve a complex terrain is using the 'Marching Cubes Algorithm' and a density function. The density function produces a float for any (x, y, z) point in our world space. If the value is positive then the coordinates are inside the terrain (i.e. underground) and if the float is negative then that describes a a point in the air or sea. If the value is zero then the point is on the surface of the terrain.

We split the terrain into sections and subdivide each block into smaller voxels. Using the marching cube method we input the density value for the eight vertices of each voxel and it will produce a number of polygons ranging from 1 to 5. If the block corners are all positive or negative the block lies completely inside or outside the terrain. The density function creates thes points based on terrain displacement techniques such as noise etc.

If we store each density value for a voxel as a bit and concatenate them into a single integer between 0 and 255 this will tell us if a block is inside or outside the terrain. If the number is between 1 and 254 then we use a lookup table to determine how many polygons to create.

Geiss, R. GPU gems 3.

Worksheet 4- The Final Frontier

2008-11-12T05:39:00.000-08:00

Proposal Document

Worksheet 4

Introduction

What is the topic and aim of the project?

The aim of the project is to identify the methods used to implement a real-time, procedural planet, in a game situation; that make the best use of modern graphics cards. The methods that will be investigated are algorithms for texturing, mesh geometry and level of detail. Conclusions will be drawn on the techniques that produce the best compromise of aesthetics and performance (frame rate).

Issues

What issues do you want to address.

The techniques for creating large scale, procedural terrain have been around for many years. Methods such as the diamond-subdivision technique, fractal-brownian motion and procedural texturing have been around since the mid 90’s and even earlier. However the best examples of procedural worlds have always been the product of an offline process; using programs such as F. Kenton Musgrave’s ‘Mojoworld’. Very few games, with the exception of ‘SPORE’, have incorporated a vast procedurally generated terrain since it was used in ‘Frontier: First Encounter’ in 1993. This raises the question ‘why not?’ Is this technique too computationally expensive? Perhaps there is no need to include this technology, but with greater demand for ‘sandbox’ games surely a procedural planet or universe is the ultimate ‘sandbox’ experience, and is far more efficient than loading the entire world mesh in.

The algorithms that have previously been used to create these planets are not designed specifically to utilize the GPU effectively. It would be interesting to discover any algorithms that exist which achieve this. Another issue that can be addressed is whether the most commonly used methods such as ROAM can be adapted to work on the graphics card. With the recent advent of the geometry shader; can this be the most effective way to tessellate the mesh?

I think that you’ve addressed some great issues here with procedural generation methods. I noticed last year with Matt’s lectures how old all the techniques seem to be, although there is an active community still doing some impressive things with them today. You’re also right to talk about how absent the methods are, with all their positives, in games. Spore is the only one I can think off too that uses them in major ways. I think you should focus on Spore a little, especially on its development and how much it was delayed to see if any conclusions can be drawn to how hard getting these methods to work in a major game.

With processing going multi core and faster all the time the major con of these methods, computational work, are getting less and less significant. Indeed this increase in processing applies to GPU’s too. With modern graphics cards becoming extremely fast also they could and should be able to handle procedural rendering and it would be interesting to see how they fair leaving the CPU to get on with other things. This will require some low level coding though getting the method’s to work on the GPU and if you’re confident enough then this is fine.

Research question

What is your current research question?

"In the development of a real-time, procedural, planet for a game situation, what are the techniques for geo-morphing, mesh geometry and texturing that best utilize modern GPU's?"

Addressing the Question

How do you envisage yourself carrying out the project - a short exposition of the project.

In order to answer the question and draw reasonable conclusions, I will need to create a procedural planet in a graphics API in this case OpenGL. In order to effectively simulate a games situation the application will include aspects such as collision detection. I will identify the most common techniques used to create a planet (at this stage it appears to be ROAM 2.0) and will then identify the elements of this algorithm that can be implemented on the graphics card and alter the technique to work accordingly. I will then create a planet using this technique. As I am using OpenGL, I will need to discover the element for storing vertex data that works best with shader technology; I think that a Vertex Buffer object is the technique I will use. I will then implement one of the more current algorithms (the one used in the game Frontier: First Encounter) that does not have its roots based in the ‘diamond sub-division’ technique. Finally I will use the Geometry shader to implement the sub-division of the mesh. From this I will be able to conclude the methods that give the best compromise of frame-rate, aesthetics, least mesh construction issues (i.e. cracks and popping) and ease of implementation and decide whether it is worthwhile, in terms of performance; including the planet in a gaming situation.

This all makes sense. It’s clear you have a good game plan in mind. Using the current techniques and improving on them is smart, such as ROAM, and will lighten your loadto get on with implementing them on the GPU.

Progress

What have you managed to do so far and how has this influenced your vision?

Having completed the procedurally generated terrain module last year, I already had a knowledge of some of the basic techniques used in the creation of a small scale terrain, including, faulting, particle deposition and midpoint displacement. However I did not really understand the techniques used to create a planet. I broke the project down into various components; level of detail, texturing and terrain displacement. I identified the most commonly used techniques for each section, such as ROAM, geo-mipmapping, detail mapping, procedural texturing, fractals etc and researched their benefits and drawbacks. It was at this stage that I realized how old many of these algorithms/techniques were. However I began to worry when I could not find any more modern techniques, instead what I discovered was that people kept tweaking the basic algorithms to optimize them. It was at this stage that I wondered why this technology was being overlooked in game development. I felt that this technology had a place in modern gaming and the release of SPORE boosted my confidence. It was fortunate that I decided to research the use of geometry shaders, I did not really understand what they were used for and had no idea they could be employed in my project. Originally I envisioned a hybrid program that tessellated the mesh on the CPU and ported it across to the graphics card. Geometry shaders would allow me to do this on the GPU itself.

I have begun work on my terrain framework by setting up OpenGL, incorporating CG shader code and creating VBO’s and vertex structs. It was in doing this that the thought occurred to me that the way in which I used the API would have an effect on the performance of my planet. I realized I had to carefully select the methods used to store the vertex data etc.

Speaking to my technical supervisor has helped shape the vision of the outcome of the project. I was losing focus and was imagining a planet covered in foliage with clouds etc. However Matt Bett reminded me to focus on the relevant tasks, so the perception of my final planet has altered slightly.

It seems you’re on your way with coding already underway. Your progress so far seems yp to scratch, especially with meeting with Matt. Using the traditional techniques on the GPU will be interesting and if all goes as planned could change the ways game are implemented in the future. Procedural generation but at no or little cost of the CPU could lead to interesting design choices with things such as improved, more resource hungry, AI jumping into the fold for example. I look forward to seeing the results.

Geometry Shaders: Triangles for everyone!

2008-11-06T11:43:00.000-08:00

I had read the word 'geometry shader' a fair deal during my research; but wrongly assumed that it was merely a vertex shader designed to handle primitive shapes. However this week I discovered that the two are very different. The geometry shader is executed prior to the pixel shader (PS) but after the vertex shader. Unlike the vertex shader (VS), the geometry shader (GS), takes in a primitive shape, for instance the three vertices of a triangle, and emits more primitives. This is an entirely new concept from the 'one in one out' implementation of the VS and PS.

The benefits of this shader for my proposed application are that the triangles can be tessellated directly on the GPU rather than on the CPU and buffered across; also face normals can be calculated on the GS by passing in the three vertices of each polygon. Obviously the crux of my program is based around the optimum implementation on the GPU; so on first reading this seems to a great deal more effecient than ROAM etc

However I discovered a post of caution on a GameDev forum, posted 2007, stating that the user had problems with performance when implementing a GS. The post said that due to the fact that it was an extremly new technology it was unusably slow. Lets hope performance has improved since then; although I have not seen any similar complaints before or since.

Your once, twice, three times a worksheet....

2008-11-06T03:07:00.000-08:00

I had previously forgotten to include the module worksheets on my blog, so here are the three worksheets completed up till now. Basically they track my progress from initial concept until my draft proposal and have been annotated and criticised by other students. Back to normal posts as of next week. I will be researching detail maps and geometry shaders.

Preliminary Concept
Worksheet 1

1.State the topic of interest that you may wish to take forward into a project.

Real time generation of planetary bodies; with increasing level of detail.

Indicate the issues surrounding this topic that you may wish investigate.

Most procedurally generated terrains map only onto a flat grid; as there are few times when a game requires an entire planet to be created. One of the main issues is finding a technique which can map to a sphere with little distortion.
A vast number of procedurally generated landscapes use static algorithms such as faulting. These are used to populate a height array which in turn is used to alter the height values of each cell of the mesh. This is fine when creating a terrain on a small scale but with a planet the size of the height array and mesh would need to be huge. I would be investigating more dynamic means of creating the mesh such as ROAMing or other adapting mesh algorithms.

There are many of these algorithms that vary in speed and most of them produce patterns on the terrain that are noticeable from distance.
When zooming in and out on the planet it is important to alter the level of detail. It is important to make the transitions as seamless as possible.

3.Outline your initial ideas about how you would carry out the practical aspects of the project. i.e. what do you envisage yourself actually doing for the project.

I will create either a single planet or more likely a selection of planets with varied geological features. I will experiment with different ways to create the planet mesh using various static and dynamic algorithms; and highlight the performance differences.

I will use various combinations of terrain distorting algorithms such as faulting, perlin noise etc to eliminate the repetitive patterns and discuss which have been most successful and whether there is a performance trade off.

I will alter the level of detail as the user zooms in adding basic procedural plants etc the closer the camera gets to a planet, once again I will use a combination of methods to identify the best result.

Seems well thought out, and that you have considered your topic. I cannot think of anything that could be changed to make any improvement as you seem to have considered everything of major importance.

Worksheet 2

Defining a Research Question

1. Formulate a research question for your project.

The ROAM(Real-time Optimally adapting mesh) algorithm and other CLOD (continuous level of detail) algorithms are based on the diamond sub-division technique and have been used in to create large scale procedural terrains since the mid 90’s. They were not designed to work on graphics cards. In developing a procedural planet what are the alternative CLOD algorithms that best utilize modern GPU’s?

2. When developing a research question you must produce a question that can be answered by performing literature research, practical experimentation and critical analysis. question should also focus the activities of your project.

a)What is the focus of your project?

To identify possible alternative algorithms to the most commonly used technique, diamond subdivision style, that work to utilize modern GPU’s. In order to use ROAM on the graphics card the algorithm must be tweaked to send the vertex array data every frame to the gpu. This can create bottlenecks on the graphics pipeline.

Are the alternative modern algorithms better than the current ROAM method and if so which one is the best?

b) What information do you need to find out about?

I need to find out about the nested quad tree algorithm and the tessalation algorithm (non-RTIN equilateral spiral wound view dependant mesh). I need to find out exactly why roam is still used so often despite it not being optimized to work on GPU’s.

I also must identify which terrain techniques (i.e. fractals, midpoint displacement, faulting) work best with each algorithm.

c) What Experimental work do you need to perform?

I need to create a procedural planet algorithm using the tweaked ROAM method of CLOD and the same planet using the other CLOD methods. I must incorporate into this a variety of procedural techniques to alter the terrain such as faulting and fractals. Each planet will be rendered using the graphics card.

3. How will the information that you obtain in 2 allow you to answer the research question?

I need to compare the frame rate, the aesthetic value, how smoothly each planet morphs between detail levels and which algorithm produces the fewest ‘cracks’ in the terrain and come to a conclusion on which one is best. I must also take into consideration how simple each algorithm is to implement. By studying how each algorithm works I will be able to suggest a hypothesis about which algorithm will be best.

Well overall you seem to have a good idea on what you are wanting to do for your honours project. SO therefore the only thing i'm going to do istTo give you a head start and that would be to go and get the focus on the 3d terrain book from the library. GO NOW! The first four chapters you don't need to read but after that its got everything you need to know about ROAM, clod and even quadtree algorithms. Infact it even talks about some algorithms that have been optimized and freindly for the GPU. But remember when you take out the book please get the c.d. That has plenty of whitepapers on other people's algorithms. But yeah i hope i was a better help than your last guy. I would go on to speak about your ups and downs of these algorithms but all this information is in that book, just means you have a little bit of reading to do. I hope thats ok with you.

Draft Proposal

2^nd November 2008

Introduction

What is the aim of the project (general overview)?

The aim of the project is to identify the methods used to implement a real-time procedural planet, in a game situation; that make the best use of modern graphics cards. The methods that will be investigated are algorithms for texturing, mesh geometry and level of detail.

Interesting topic, especially with regards to games such as Spore and Eve Online, which either do not bother with further detail on planets (you can only orbit) or stutter as the game loads up new models to display the planet.

Motivation

Why do you want to do this and why would anybody be interested in what you want to do?

The concept of procedural terrain has been around for many years, however only a select few games have implemented large-scale terrains in a game. The most common implementation of procedural planets are for artistic purposes, such as F. Kenton Musgrave’s Mojoworld. However these are rendered as an offline process. Now that modern graphics technology has improved dramatically in the last ten years, I wondered why so few games make use of procedural planets as they allow for unique, natural looking terrain to be produced quickly and frequently; especially given the current demand for ‘sandbox’ worlds, surely an entire planet or universe is the ultimate ‘sandbox’. The most widely used techniques for procedural planet generation date from the early to mid 90’s and are not designed to effectively work on GPU’s. I thought it would be interesting to find out what algorithms there are that utilize the GPU most effectively or whether the current algorithms, such as ROAM can be modified to work on GPU’s. Ultimately this will enable me to conclude whether it is feasible to incorporate a procedural planet into a gaming environment.

I think you are correct in believing that this topic will generate interest as it's based around two currently popular topics- procedural content and utilising the GPU's processing power. I also agree with your statements on an infinite universe being the ultimate sandbox. The notion that you and a friend could both play the same game but have completely different experiences due to the shape of the geography is quite attractive.

Research question

"In the development of a real-time, procedural, planet for a game situation, what are the techniques for geo-morphing, mesh geometry and texturing that best utilize modern GPU's?"

Addressing the Question

What will be done to answer the question?

In order to answer the question and draw reasonable conclusions, I will need to create a procedural planet in a graphics API such as OpenGL. In order to effectively simulate a games situation the application will include aspects such as collision detection. I will identify the most common techniques used to create a planet for example, ROAM, Geomipmapping etc and will then identify the elements of these algorithms that can be implemented on the graphics card and alter the techniques to work accordingly. I will then create a planet using this technique. As I am using OpenGL, I will need to discover the element for storing vertex data that works best with shader technology; I think that a Vertex Buffer object is the technique I will use. I will then implement one of the more current algorithms (the one used in the game Frontier: First Encounter) that does not have its roots based in the ‘diamond sub-division’ technique. From this I will be able to conclude the methods that give the best compromise of frame-rate, aesthetics, least mesh construction issues (i.e. cracks and popping) and ease of implementation and decide whether it is worthwhile, in terms of performance; including the planet in a game

This description gives a clear and informed explanation of the project's implementation. There does not appear to be any obvious area that you have missed out, as framework, algorithms, further research and success definition have all been listed.

Resource Requirements

What equipment/resources will be needed/used?

The implementation of my project will not require much equipment. However I will need to create an OpenGL framework in Microsoft Visual Studio 2005. The framework will need to incorporate CG pixel and vertex shaders. I will be using a Nvidia 9600GT graphics card to run my application and will be testing the results on a ‘Duo Core’ and ‘Quad Core’ system. The algorithms that I will be using for the displacement of the terrain will be a mixture of faulting, fractal Brownian motion, Perlin noise and particle deposition. The level of detail techniques that I will be using are ROAM 2.0, and Triangle Tessellation Structured. Finally I will use procedural texture generation and detail maps to colour the planet dependant on height, latitude and normal angle.

Again, solid list of requirements detailing everything required. The only thing not mentioned is how you plan to measure your success definition. Performance would presumably be a frame rate counter and aesthetics will either be self-defined or surveying a few people's opinions. The hardest to measure will be ease of implementation- after months of working on it the code will be known inside out, but I can not think of an alternate to personal assessment.

Gentlemen. Start your engines!

2008-10-24T06:18:00.000-07:00

I mentioned last week that I was going to implement a basic subdivision algorithm; however I forgot that I really needed a framework first. I had trouble deciding whether to use one of the graphics API's or a game engine such as OGRE. I eventually decided to use OpenGL, for no other reason that it is the API I am most familiar with. I created my OpenGL framework based on the NeHe window - http://nehe.gamedev.net and organised it into a more class based system. Although the actual implementation will not begin until Christmas I felt it was important to create the basic framework and perform some experiments; this will let me identify any issues I could focus on during research.

There was nothing left to do but start.....It was at this point I realised that no paper on spherical CLOD that I have read mentions the best way to store the vertices, so I decided to go with my own intuition and use VBO's as they make good use of the GPU. I had a few problems initialising the VBO framework but this was due to GL extension file issues and after much frustration, tantrums and linking errors they finally worked.

Good. Next task was to decide on the basic shape. The obvious starting point is a geosphere but this is really quite difficult to plot and I was not in the mood by this point. I read that plotting a cube works equally as well and with enough subdivisions morphs into a sphere (although it does take more splits) and thankfully it is alot easier to plot the vertices of a cube.

Now I just need to set up the member pointers of each polygon and its neighbours at a later date. This, thankfully, is much easier to initialise with a cube too.

I have tweaked my research question slightly which ties it to computer games technology more.

"In the devlopment of a realtime, procedural planet for a game situation, what are the techniques for geomorphing and texturing that best utilize modern GPU's?"

God said "Let there be textures"

2008-10-20T04:14:00.000-07:00

This week I decided to investigate (briefly) how I was going to texture my planet. I must admit that, at first, texturing was something of an afterthought. I was always planning on texturing my planet, however this was not really going to be a focal point in my investigation. Fortunately my technical supervisor highlighted the fact that at a far distance texturing is all that matters; as the geometry of the planet (the terrain displacement) need not come into effect til the user is close enough to the terrain to actually view it. Texturing can also bring the planet to life and can help compensate for slightly unnatural looking terrain.
My plan is to separate texturing into two parts. Firstly from a far view point (i.e. space). I feel that from this distance the optimal thing to do is to load in several levels of discrete textures (a bit like mipmapping). These will vary in level of detail until the camera reaches a certain altitude. This is more efficient than generating textures every frame when the camera is so far away from the planet that it can only make out the shapes of land and sea.

The next section will involve using the pixel shader to generate the textures. The textures will be generated based on height, angle of incline and distance from the equator (by latitude). There is a good section in the book "Texturing and Modelling: A Procedural Approach" on how to shade with a matte effect to create nice earth textures.

Im thinking about knocking up a quick planet sometime in the next few weeks to implement the diamond sub-division algorithm and no doubt that will raise a few issues!

Research Question & Finally another CLOD algorithm!

2008-10-13T05:58:00.000-07:00

Yesterday; I finally narrowed down this procedural topic to a specific research question. The question had to address a problem with this area of computer games. I was debating whether to go with a broad topic such as the implementation of entire procedural planets in games but Spore blew that out the water by implementing an entire procedural universe. I will research the methods that Spore used to achieve, this but from an early stage in my research I discovered that ROAM, although an older algorithm, was still the method of choice. I decided that I would like to investigate alternative algorithms (i.e. ones that were not based on the diamond sub-division technique) however this seemed to present a problem...I could not find any! Thankfully yesterday provided a bit of a breakthrough and I found a gateway to alternative level of detail algorithms. My question was decided:

" In developing a procedural planet what are the alternative CLOD algorithms, to the diamond sub-division, for geometry and textures that best utilize modern GPU’s?"

Basically I intend to identify which algorithm produces the best results, in terms of speed and aesthetics, when creating an entire procedural planet. Hopefully by comparing several algorithms I will be able to identify the pros and cons for each one, the ease of implementation and draw conclusions on which one is best or perhaps suggest a hybrid of the methods.

An alternative Approach

One of the alternative CLOD algorithms that I found was the triangle tessellation algorithm suggested by Andrew True in his "Procedural Planets" article. This algorithm dictated what to render based on the viewpoint of the user. One of the major differences between that and the diamond method is that the sphere mesh is created in a spiral of polygons. Apparently this is the technique used in the game Frontiers: First Encounters. The structure starts with a basic triangle, each triangle can be affected by one of two procedures, it can be split to form four child triangles or, if it has a parent, can be combined. Each triangle must keep track of its three neighbours and whether that neighbour is a child, parent or an edge. A triangle cannot split so that it becomes 2 orders above that of its neighbour, for instance if I have four kids and my neighbour has none, he must split before I can. A split is achieved by finding the midpoint of each edge and creating four new children. Effectively to see more of the planet the triangles are combined by deleting the child nodes. A triangle cannot be combined if it has 'grandchildren'.

Two of the biggest advantages of this algorithm over ROAM is that it uses less recursions to split and combine and the philosophy of the algorithm is don't have cracks in the first place! ROAM creates cracks in the mesh when a large triangle is neighboured by smaller triangles which try to distort. ROAM distorts triangles as it splits or combines them and this often results in children being displaced before there parents have been split. ROAM then tries to connect the now larger triangle with the other triangles by dividing the large triangle in as few loops as possible; the new algorithm just avoids cracks from the outset. It achieves this by only distorting a triangle if the neighbour of that triangle has children; the grandchildren are then also given permission to distort. If we are not split then our children have not been displaced and as a result our children cannot be displaced until we have been split.

Hopefully this algorithm will prove quicker than ROAM and more efficient as recursions are not wasted trying to fill gaps in the geometry.

Next Post: I have been pointed in the direction of an optimized version of ROAM called SOAR, so I am going to read up on that. I should probably now begin to focus on the texturing aspect of the planet, as the geometric LOD only comes into play when the camera comes close enough to view the terrain, at all other times the textures will convey the detail level.

ROAM - What is it? What are its problems?

2008-10-12T07:13:00.000-07:00

I feel that the ROAM algorithm will become such an integral part of my dissertation and application that it is best to identify what exactly it does, why it is used and what are its drawbacks. ROAM (Real-time Optimally Adapting Mesh) is a continuous level of detail algorithm, used when creating vast procedural terrains. It uses quad trees to subdivide the mesh's triangles; allowing the program to concentrate a higher number of polygons at the area of the terrain that the camera is viewing. A triangle is split along its mid-point. The order is decided by assigning each triangle a 'split priority'. Effectively this means that although there are only ever a fixed number of polygons on screen and that a patch of terrain is allocated more polygons and therefore has a higher level of detail. This is done by merging triangles that aren't being viewed. A triangle can only be merged if its in a diamond step.

ROAM 'walks' its quad-trees every frame, checking every vertex of the mesh to identify if a new split or join is required and must also alter the positional data of any vertex that has now changed (i.e. this vertex is now used in a mountain, its y value has increased). In order to utilize the power of modern graphics cards the data must be transferred quickly and compactly. This usually means using vertex arrays or VBO's. As ROAM allows for the insertion and deletion of vertices, the algorithm is not suited to fixed array sizes and this is why it is often never used in conjunction with the GPU.

However the algorithm does allow for smooth morphing of terrain and does account for cracks in the terrain created by the diamond subdivision technique that ROAM uses and ROAM is very good at what it does it was just never designed to work on the graphics card.

Ideally an algorithm that splits the terrain in various sections would be the most efficient. By dividing the terrain into smaller sections only one array would need to be updated when the terrain altered allowing the other to 'remain' on the GPU. This means only transferring one smaller array each frame.

Next Post - Research Question & Alternative CLOD algorithms.

Level of Detail and Terrain Algorithms

2008-10-09T03:01:00.000-07:00

I have been assigned a technical supervisor to help me conquer procedural planets. I am going to arrange a meeting to help identify the areas I should focus on in order to formulate a research question. I was debating whether to do a 'compare and contrast' between static meshes and dynamic meshes. However it seems that nobody in the world would ever use a static mesh for this kind of application as the memory issues are to great. I am tending toward a study of the pros and cons of CLOD (continuous level of detail) algorithms Vs DLOD (discrete level of detail algorithms) or a comparison of different CLOD techniques.

I have done a bit of research into various LOD algorithms and it appears that ROAM is the technique of choice; due to it's speed and it's simpleness. DLOD requires a variety of pre-defined meshes at varying detail level. As the user zooms in and out these are loaded in order. CLOD adapts the terrain depending on the user distance from the mesh. At any level there will be the same number of polygons on screen, they will just be arranged differently. ROAM achieves this by subdividing triangles; triangles out with the viewing plane are ignored. ROAM is an older algorithm and is not designed to work on GPUS's and does not make use of systems with multiple cores. It would be interesting to see how a modern CLOD algorithm compares.

I could also do study evaluating the various procedural terrain techniques. I did discover that not all the techniques are suited to CLOD. I have worked with a few algorithms previously so am familiar with them; however the techniques must be altered to work on a sphere rather that a plane. The stipulations for the algorithms are that they must work over a large scale, must be quick and require as little smoothing as possible and must be able to be altered in a 'local' space (i.e. the area on screen) without changing the whole noise mesh.

Various sources say that the Midpoint Displacement algorithm is usually used with ROAM and Perlin Noise is ideal for the various detail levels. Midpoint Displacement can lead to a large number of 'cracks' or ridges in the terrain. Faulting is useful when used sparingly as it makes the terrain appear more natural, however it can require a lot of smoothing to appear undulated.

Tasks for next week:

Identify alternate CLOD algorithms.
Meet with Tutor
Form Research Question

With any luck we will make a planet yet....I'm feeling a bit God-like only without the beard.

Topic Has Been Chosen People....

2008-09-28T08:20:00.000-07:00

Its as much as surprise to me as to anyone, that after a bit of light research, I have decided to stick with the topic I had originally planned to do; and not switch to modelling porcupine behaviour.

I have decided to investigate and hopefully do some writing about..."Real time generation of planetary bodies; with increasing level of detail".

This will ultimately involve creating a number of planets, each with varied geological features, in real time (i.e not loading in a pre-built mesh). The program will enable the user to zoom in and out and the level of detail will adjust accordingly (and with any luck smoothly) to show plants, grass beaches or just mountains and oceans. The main aim of the investigation will be identify the best methods of achieving this and comparing and contrasting existing static and dynamic algorithms. I will then discuss the performance and aesthetic issues of each combination of techniques. I envisage some spore style mini planets rather than full blown gas giants, but the principle is the same.

Having only done brief research over tea and biscuits I should probably do some heavy reading on distorting a spherical mesh, ROAMing (Realtime adapting mesh algorithms), dynamic LOD algorithms and procedural texturing and plant life (luckily I know of a book "Modelling hairy plants"!). Basically this is what I will be doing over the next week. Oh and I'll hopefully have an actual question to research within the next couple of weeks.

"In the event that my idea and beautifully written concept document get torpedoed at the first hurdle then....forget everything I just said!"

Why Blog?

2008-09-28T06:44:00.000-07:00

The purpose of this blog is to act as a log of the events and progress of my 4th year honours project. The first task will be to decide on a topic to study....I'm thinking some kind of procedural world generation but let's be honest who knows! Bring on the realistic plants!