Messages

16

Design / Re: Improved Air Combat (coming soon...)

« on: November 18, 2012, 08:55:55 am »

wow thats really cool! Will there be any city backdrops for air combat, like when the UFO flies over urban areas?

There could be, possibly.

I've actually got more than one idea on how to implement cities and densely-populated areas.

One idea is to create the terrain and then plunk down a ton of static meshes of city buildings, much like how I did with trees, they would be VERY simple building models with no more than perhaps a dozen or so faces, so that a large number of them could be rendered on the terrain at once.

Another idea I've been thinking about, one that perhaps might work better depending on how it is done, is to totally replace (get rid of) the terrain for city areas and instead of building a terrain mesh, simply use different algorithms to create streets and buildings.  If this second idea was done right, it could work quite well IMO.  I'll really have to do some tests to try this out.  As far as the textures for the buildings in this second idea, that would actually be rather easy, it could be done with several grey-scale textures lumped together into one texture file, so that several "base" starting textures are used for variety in buildings, and then after mapping the texture use vertex colors to color the buildings differently, so the resulting combinations of buildings would be a fairly large number but without using too many resources on the rendering system.  I know how to do this in Irrlicht but will likely need help from a few others with coding it to work in UFO AI's render engine.

An alternative is to map two textures to a city mesh, in layers, so that one would have the grey-scale textures and the other would be a low-res collection of colors for coloring the faces.  The only big issue with this idea is that all the faces would need two independent sets of texture coordinates for the two different layers.  I don't know how well OpenGL can handle that, I'll have to do some research on this version of my idea.

17

Coding / Re: (Technical) Terrain Generator for Air Combat and possibly other stuff...

« on: September 12, 2012, 04:15:05 pm »

Sorry everyone, I used the wrong compiler settings for the new version, you can find a version built correctly for 32-bits at: http://www.destructavator.com/ufoai/TigersEye3.7z

18

Coding / Re: (Technical) Terrain Generator for Air Combat and possibly other stuff...

« on: September 12, 2012, 03:07:03 am »

Still haven't studied the code in detail, but it appears to me that your 4x4 texels per grid cell texture is just to add some random variety, right? Indeed, if you just render non-textured vertex-colored landscape, that will be not fun. But direct-mapped texture will grow to fast with increase of resulution, so IMHO it is not the way to go.

On the other hand, even while staying strictly within OpenGL 1.3 and OpenGL ES 1.1 limitations we can do detail rendering in the very different way: define extra "overlay" texture and use some other noise (or not) texture to select or blend between vertex-defined color and the "overlay" texture color to create the fine detail.
If you can live without colored lights (which will require baking into both vertex colors and overlay texture), overlay texture can be mapped in tiled way, which, if combined with some odd scale and rotation can make for detailed and still (visually) non-repeating texture pattern.
Even more, if we allow it to be mapped in non-contiguous way (easy with UFO:AI, since we are rendering triangle soup anyway), it can be used as a sort of
"overlay texture atlas", which can contain some grass patches, scattered sand or gravel, or more realistic cutoff of snowy areas, dissolving into series of small heaps before disappearing (just use a binary, on/off noise texture for that).

Just a small idea based on knowing how OpenGL works and a bit of imagination

Please check out http://www.destructavator.com/ufoai/TigersEye1.7z

Also a second revamped version is: http://www.destructavator.com/ufoai/TigersEye2.7z

For anyone else who didn't see the IRC discussion about this, this latest link goes to a demo that sort of uses Sandro's idea, and yes, it works much better and runs faster.

19

Design / Re: Improved Air Combat (coming soon...)

« on: September 01, 2012, 05:45:48 pm »

...Also, some sort of fog/haze could be used to add visual depth -- scene is supposed to be a few kilometers deep, no?

There should already be some type of OpenGL-based fog effect for distant parts of the terrain, as seen in some of the screenshots in this thread.  I already programmed that in, although I'm not sure exactly how the Irrlicht engine implements it - It might be possible that Irrlicht was trying to make the fog happen with a method that doesn't work as well with your graphics hardware as well as it does with mine (likely the engine's fault, as it is a development trunk branch of Irrlicht, or it could just be your default OpenGL settings for new applications - I know that Nvidia drivers, for example, often mistake many applications and even UFO AI as being totally different programs by mistake and then apply the wrong 3D display settings).

Regarding terrain colors, those are easy to change.

Even more, if you can make generator to be fast enough, there will be no need to exit combat when leaving the tile; just generate extra one (or two, or even three which is the worst possible case) and continue. Actually, you will have to keep a 9-tile cache and update it as the dogfight moves from one tile to another.

Yes, that's a workable idea.

----
BTW, I think I may have found the culprit behind trees not sitting level on the terrain (when up close, some are floating a little, others are dug into the terrain) - The terrain and the objects sitting on it are in two vastly different scales for the position of each vertex, and the system currently writes the generated WaveFront OBJ files using float (32-bit) math, and then only writing out 5 or 6 decimal places in the files for vertex positions.  If I change the precision and then also change the number of digits the program writes (It uses a standard ofstream from the C standard library, and I already know how to tell it to write more digits), it might solve this issue.

20

Design / Re: Improved Air Combat (coming soon...)

« on: August 31, 2012, 09:08:40 pm »

terrain_test_5.7z doesn't open in the last version of 7zip (9.20), claiming that archive is damaged. Investigation shows that file ends with a long train of zero bytes instead of data. Tried to redownload it, result is the same.

I'm not sure what happened there - I tested the link myself and surprisingly ran into the same problem - but I've uploaded a new archive.  Please let me know if version 6 unpacks and works OK for you.

21

Feature Requests / Re: Air combat alternative

« on: August 07, 2012, 04:00:03 am »

I agree, we certainly could use more aircraft items.  The aircraft as well as the air combat system is underdeveloped in this game, it has been that way for a long time.

I'm one of several individuals with this project who is already working on a new, revamped air combat system - I'll keep some of these ideas in mind.  Hopefully when a new air combat system is in place, other related parts of the game - such as using a stealth aircraft to follow and study a UFO on the geoscape - will soon follow.

22

Design / Re: Improved Air Combat (coming soon...)

« on: August 07, 2012, 02:39:19 am »

After a lot of hair-pulling, cursing and swearing, and frustration I finally got my new terrain code to work better and include dotting objects all over the landscape.

I've done quite a bit of work on it and have improved many parts of the code for it.

Right now, it just sprinkles trees, which only have two main varieties:  A standard one and a snow-covered version of the standard one.  The generator algorithms and maths help decide which version to put in a spot based upon the terrain there.

Yes, the trees are very basic, very simple and crude-looking up close, but they need to be that way to run the terrain and objects in realtime.

There is a hard-coded index limit of just 16 for every model sprinkled on the landscape, whether it is a tree, rock, building, alien launch pad, whatever.  This is to keep the whole scene running fast enough on most computers for realtime.  What this index limit means is a max of just 16 verts, 16 faces, 16 normals, and 16 texture coordinates (as per what the OBJ format allows) for every little model sitting on the terrain.

Of course, that 16 limit does not apply to additional models independent of the generated terrain, such as aircraft fighting in the sky above or around it.

I'll upload a new version of the stand-alone demo app for people to play with in a few moments.  It currently can create ~4 to 5 different basic terrain types, which is a fraction of what the code supports (I have not configured the parameters for other terrain types yet).

Note:  The textures on the terrain objects are a different story, they can be detailed graphics if desired, right now the trees share a combined texture map image that is 1024x1024 pixels, but the vertex count and number of faces are the real limitations in the code.  So if anyone wants to contribute very simple models to put on the terrain, go for it.  I can especially use man-made buildings and structures and such, as well as alien design, for UFO AI.

Finally, I'd like to point out that the object generation can be controlled via parameters for changes in density according to altitude, whether or not the object is above the water plane or not, etc., as well as clumping and clustering of the objects.  Each parameter "slot" in the code for the map can also repeat the same object type (or of course mix different object models) with different values, as well as scale and size factors.

23

Discussion / Re: UFO: AI 2.4/2.5 Lets Plays

« on: July 12, 2012, 11:51:43 am »

I don't have time to make an "official" gameplay video that properly shows how the game works, but I do have a YouTube account that I've had for a long time, I'd be happy to upload a proper video under my account if someone else makes one.

I also have professional pro audio recording gear including some very good vocal mics for a professional narration, and non-linear video editing software to add final touches and put it together.

EDIT: Well, OK, I suppose I could make the time to put together a short video that shows a few missions at the start of a game, but if anyone wants to see stuff that is only shown later in the game, they'll have to submit recordings for me to include a few clips.

24

Design / Re: Alien Design: The Gaak

« on: June 18, 2012, 02:26:07 pm »

Ah, Okay, so the intellectual property rights won't be an issue - Any author can of course copy and base off of their own ideas from elsewhere - That's good news.

The question then is twofold: The first of which being if the concept for this alien can be adapted to fit the context of UFO AI as an alien race, including being infected like all the other races.  That's the easy part, because even if there are a few parts that don't fit initially I'm sure they could be changed or tweaked (I admit I haven't used a translator on the text yet), until it does fit in the game's universe.

The hard part would be to get someone to build a 3D model, texture it, animate it, and do all the other work needed so it actually shows up in the game.  On that point I've actually been wanting for some time to model and add a new alien race to the game, but I've got other stuff going on - including other contributions for this game - to the point that if no one else accepts the job it would likely be some time before I could get around to trying to create this alien in Blender.  I think I have the skill to do it - I still use Blender quite a bit and have maintained my skills with the software - but there's just the issue of *time* and the fact that I have to work for a living with a "day job."

25

Design / Re: Alien Design: The Gaak

« on: June 18, 2012, 06:02:12 am »

Ack, my German is terrible, I could spend a good hour on a massive paragraph like that and only make it through about half-way, while still only understanding some of it.

For many of the other forum members here who don't know any German at all, it would be even harder to offer comment.

Could you please clarify where this came from?  At first you say it is from some book or something, then you say it is from some professor.  Is this your own, original work that you have all the rights to?

Could you please also provide even a short, simplified summary of the alien in English, even if you don't translate the whole thing with all the details?

26

Feature Requests / Re: Mortars

« on: June 15, 2012, 12:16:13 am »

*Cough*Plasma blade*cough*

~J

If you mean the Plasma Blade item in UFO AI, yes, I've known about that for as long as since it was added to the game - And unless things were dramatically changed lately and no one told me, it doesn't function the same as the light-saber weapons from Star Wars.  It does have a few similarities in common, yes, but still distinctly different.

27

Feature Requests / Re: Mortars

« on: June 14, 2012, 07:46:50 pm »

With the naked eye, hopefully.

If it's really that big, you might want to consider sunglasses if you plan on ever being able to see anything afterwards...

28

Coding / Re: (Technical) Terrain Generator for Air Combat and possibly other stuff...

« on: June 14, 2012, 06:46:48 pm »

The map code will also support dotting the landscape with tiny, simple objects depending on the type of terrain, although I haven't written all the code for it yet:

Code: [Select]

enum TerrainObjectType
{
tno_Tree_Basic,
tno_Tree_Palm,
tno_Cactus,
tno_Shrub,
tno_Boulder,
tno_House_Farm,
tno_House_Town,
tno_House_Estate,
tno_Park_Small,
tno_Park_Large,
tno_OfficeBuilding_Small,
tno_OfficeBuilding_Medium,
tno_OfficeBuilding_Large,
tno_City_Complex_Small,
tno_City_Complex_Medium,
tno_City_Complex_Large,
tno_City_Complex_Large_Tall,
tno_Military_Installation_Small,
tno_Military_Installation_Medium,
tno_Military_Installation_Large,
tno_Factory_Small,
tno_Factory_Large,
tno_Industrial,
tno_Mine,
tno_Airport,
tno_Stadium,
tno_Alien_A,
tno_Alien_B,
tno_Alien_C,
tno_MAX_COUNT
};
This list is just a start, and can be expanded.

29

Coding / Re: (Technical) Terrain Generator for Air Combat and possibly other stuff...

« on: June 14, 2012, 06:15:10 pm »

This shows an example entry for a type of "climate" that refers to the whole map:

Code: [Select]

static const climateData mData[] =
{
{
cm_TestDemo, /* index */
11, /* number of levels (color zones) */
0.075f, /* vertical scale ratio */
0.25f, /* water table height factor */
100, /* min terrain passes */
120, /* max terrain passes */
0.015f, /* terrain pass min horizontal factor */
0.120f, /* terrain pass max horizontal factor */
1.00f, /* terrain pass vertical factor */
0.05f, /* terrain pass warp shaping factor */
0.75f, /* max terrain height factor */
fld_Water_Light, /* Type of fluid the water plane is made out of (texture) */
{
{trn_Deep_Water, 0.05f, 0.80f, 0.0f, 0.01f, 1.0f},
{trn_Mid_Water, 0.10f, 0.80f, 0.0f, 0.01f, 1.0f},
{trn_Shallow_Water, 0.15f, 0.80f, 0.0f, 0.01f, 1.0f},
{trn_Sand, 0.20f, 0.95f, 0.0f, 0.01f, 1.0f},
{trn_Grass, 0.30f, 0.95f, 0.0f, 0.01f, 1.0f},
{trn_Hills, 0.40f, 0.95f, 0.0f, 0.2f, 1.0f},
{trn_High_Hills, 0.45f, 0.95f, 0.0f, 0.3f, 1.0f},
{trn_Low_Mountains, 0.75f, 0.95f, 0.05f, 2.5f, 1.0f},
{trn_Mid_Mountains, 0.90f, 0.95f, 0.15f, 3.5f, 1.0f},
{trn_High_Mountains, 1.20f, 0.0f, 0.25f, 4.5f, 1.0f},
{trn_Alien_Purple_Dark, 12.00f, 0.0f, 0.40f, 5.0f, 1.0f}
}, /* Terrain type, Max Altitude, Color Blend, Snow Angle Max, Height Jitter, Height Level Weight */
},
...
Each climate type has multiple vertical levels with different characteristics.

BTW, sorry about the messed-up TAB length/spacing when I copy/paste from the source code.

The generator also supports four types of water planes, two for actual water, one for frozen water or liquid, and one for molten lava.

30

Coding / (Technical) Terrain Generator for Air Combat and possibly other stuff...

« on: June 14, 2012, 06:11:25 pm »

OK, if anyone wants to try my code for rapid terrain generation for use in realtime 3D animation or gameplay, I have an updated version of my demo that includes it on my website:

http://www.destructavator.com/media/terrain_test_6.7z
or the very latest with a different rendering technique (read the thread) at: http://www.destructavator.com/ufoai/TigersEye3.7z


The basic, non-technical topic which also talks about implementation is at : http://ufoai.org/forum/index.php/topic,6771.msg53947.html#msg53947

I'm designing it not just for UFO AI but also for other GPL projects as well, including some of my own.  I'll try to make it so that the code can be easily brought into nearly any C++ project.

NOTE that although the demo uses Irrlicht to display the created map, my code itself doesn't require Irrlicht, it just relies on a few basic libraries that are standard for C++.  At some point I plan to add a check for #define statements that indicate the presence of libPNG and zlib, and if it finds that they are present it will enable a few additional functions to write the created map and object textures to a file, so that the programmer doesn't have to write a loop using GetTexturePixelData() for the color values of each pixel one-by-one.

The created map can be thought of as a grid of 250x250 "spots" - each spot having several pixels of texture and other information that is retained by the instance of the terrain class after it makes the map.  The reason it isn't 256x256 is that the number of verts for the mesh that the map is made on MUST be 1 unit greater (in each dimension) than the number of spots, because each spot on the map has four corners, with most of the spot and texture data pertaining to the center or the whole square.

So the default size map is 250x250 spots, with 251x251 verts, and each spot by default (unless specified otherwise in map creation parameters) has 4x4 pixels of texture, which means the texture is 1000x1000 pixels.

If you ask "Why don't you just make it 256x256 spots anyways, with 257x257 verts and a 1024x1024 pixel texture?" the answer is limitations of the OBJ model format.  The info I've found on the format says that 257x257 verts would mean too many index entries in the model file, which some 3D engines wouldn't be happy about.

The data retained for each spot currently is in several structs for each spot, aside from the texture pixel data, there's also a struct that one can get() information from:

Code: [Select]

struct TerrainPointData
{
float cornerHeight[4];
int cornerIndex[4];
float lowestPoint;
float highestPoint;
float centerLocation[3];
float steepness;
terrainLevels terrainAtPoint;
int isCoveredInSnow;
int isAboveWater;
};
I'll eventually expand this to include population information that can be used to decide what map tiles to load for the battlescape when a UFO lands or crashes at a certain spot on the map.  The reason for the isCoverdInSnow and isAboveWater being int and not bool is that each spot could have part of it under water or snow, and other part of it not, so the int value is compared with how many sub-parts of each spot there are, to make a ratio.  (By default the demo makes the map with 16 sub-spots as 4x4 for each spot, so a value of "8" for isCoveredInSnow means half the spot has snow on it.)  The "terrainAtPoint" is an enum that holds data on the type of terrain at that spot.  The "climate type" refers to what basic type of terrain the whole map is.

Code: [Select]

enum climateTypes
{
cm_TestDemo,
cm_Temperate,
cm_Tropical,
cm_Desert,
cm_Barren,
cm_Arctic,
cm_Ocean,
cm_Mountain,
cm_Volcanic,
cm_Lunar,
cm_Alien,
cm_MAX_COUNT
};

enum terrainLevels
{
trn_Deep_Water,
trn_Mid_Water,
trn_Shallow_Water,
trn_Sand,
trn_Sand_White,
trn_Sand_Grey,
trn_Sand_Dark,
trn_Grass,
trn_Grass_Dark,
trn_Hills,
trn_High_Hills,
trn_Low_Mountains,
trn_Mid_Mountains,
trn_High_Mountains,
trn_Barren,
trn_Barren_Dark,
trn_Barren_Bright,
trn_Volcanic_Dark,
trn_Volcanic_Mid,
trn_Volcanic_Bright,
trn_Alien_Purple_Dark,
trn_Alien_Purple_Mid,
trn_Alien_Purple_Bright,
trn_MAX_COUNT
};