Are you sure about that texturing method? If someone wanted to have high detail textures, it would waste a lot of video RAM. I think it would be no problem for today's cards, but something like GF4 or older would be a different story. Also, any bigger texture modification (decals) would need a lot of computing work (at least I think). (Not saying my method is any better )
Looking forward to the rewrite. If you make any rewrite in C++, maybe I'm joining .
Coldetect works right but I think you should set a minimum distance, stuff too close gets clipped.
i probably should
also
"
i was thinking about keeping various detail levels in RAM
and re-upoading and freeing textures depending on camera position
Post"
ought to save some video card memory _________________ Micro TS
Portable, no campaign, movies or music, just the engine and needed resources for skirmish and lan. QUICK_EDIT
thanks.
also, red square is a TEST
meant to test 2d->3d matrix transformation _________________ Micro TS
Portable, no campaign, movies or music, just the engine and needed resources for skirmish and lan. QUICK_EDIT
(Detail levels)
Won't that be a bit laggy when you'll change (minimap click) position to the other side of the map (as was noted in the article)? Also, this means that all the textures will be precompiled with map, right? Modders would be able to load their own drawn/use procedural textures for every cell and the hit "rebuild" button and it compiles into these big textures? Map size will be big too, even if you png it. (Big maps will have, say, 64 256*256 24 bit textures, that's... a lot)
Anyway, the method's pretty good, use it if you can't get anything better. _________________ Time will tell...
Sooner or later...
Time will tell... QUICK_EDIT
/edit/
btw, the height-and colormaps still appear mirored. The attached pic shows the same view you get when looking at the lower part of the heightmap, only mirrored sideways <-|->
mountains.jpg
Description:
mountains :)
Filesize:
103.36 KB
Viewed:
16439 Time(s)
color.rar
Description:
Grass on the lower areas, granite grey on the mountains.
Joined: 08 Jul 2006 Location: in your closet... Post = true
Posted: Thu Jun 21, 2007 11:06 pm Post subject:
I just love reading all the way through that project-forum, although I do get NOTHING.
It just sounds nice how youre discussing *laughs insane*
Probably because I imagine what may be the result of this... _________________ audiopulse sagt:
your raging arse is creating storms?
Luke | CCHyper sagt:
yup, neptune size! QUICK_EDIT
How many texture stages will OTS be using? I assume, for performance reasons, it will use just one pass (and hence take advantage of multiple texture stages). Because for random level generation, I wanted to know if it is including such things as roads and other texture effects that extra texture stages can be used to implement.
Also, in terms of water, does OTS plan to have a feature such as 'set ocean level' which just uses a water plane placed at that height and cuts out any terrain below it. Its just because, in terms of visual effects, like waterfalls, won't work with that. I just wanted to know if it should implement some water placing technique for producing 'rivers' that flow all over the place instead of a simple bulk water mass.
Just need to know for random terrain/level gen. QUICK_EDIT
Joined: 22 Aug 2006 Location: somewhere south of the north pole
Posted: Sat Jun 23, 2007 12:09 pm Post subject:
This is getting better all the time! Thinking this is barly a beta, I cann't wait to see it "finalised" _________________ This is a signature QUICK_EDIT
Rivers would definitely be much better. AFAIK he uses one big texture per map section, so everything generated in editor would be merged into this and in-game drawn one pass (?)
Judeau: Are you rewriting it C or C++? I think I have few things in my engine I could donate (console, for instance), but that depends on how your engine is built. I should have net connection in a few weeks.
Equiredox: Are you already working on a map editor? _________________ Time will tell...
Sooner or later...
Time will tell... QUICK_EDIT
Rivers would definitely be much better. AFAIK he uses one big texture per map section, so everything generated in editor would be merged into this and in-game drawn one pass (?)
Judeau: Are you rewriting it C or C++? I think I have few things in my engine I could donate (console, for instance), but that depends on how your engine is built. I should have net connection in a few weeks.
Equiredox: Are you already working on a map editor?
As per Judeau's instructions, I am working on an auto heightmap generator. A seperate program from OTS, but to be used in conjunction with OTS. We did discuss the map editor, but Judeau believed that it will be best to leave that to later, after the engine was nearly complete.
I would prefer to use a non-plane water approach. My premise is because rivers can be done with just a large "plane" of water (such as what BF Vietnam did), and just alter the texcoords by some texture transform on every interval to have the perception of flowing water. However, the issue is the water will flow in one direction, and as a result it will look weird if you have a bend or curve or change of direction in a river. With a loss of performance, we can make a simple mesh setup for the water, such the water flows down the river - not in one direction, and waterfall effects can be produced and water can flow down hills and inbetween rocks. It doesn't just need to be water, it can be lava or any fluid. A cool volcano level maybe? But they didn't have volcanoes in TS.
I asked about texture stages, because multiple texture stages are used in most games (from my knowledge) that have large outdoor environments. What a programmer can do, is place a base colourmap down first, then on top of that use a mask (with filtering to smooth it out) in conjunction with a road texture, to produce a road on the terrain mesh surface which has a very good texture res. Also it can be used to place patches of grass, dirt, burn marks - sort of like decals - but decals that bend with the gradient of the terrain's surface. All in one pass. But I am a D3D guy, I don't know if OpenGL works the same way.
With the use of multiple texture stages, masks with filtering, in use with normal 256x256 or 512x512 grass / dirt / road textures, it will save a lot of memory on the graphics card - instead of storing a megatexture for the entire surface, as I see it (maybe Judeau has a great idea for an algorithm I don't know of yet).
Also, I was told to use C, for portability. QUICK_EDIT
Joined: 26 Nov 2002 Location: Algae Colony On Mars
Posted: Sun Jun 24, 2007 11:54 am Post subject:
Having a set water level also raises the issue of water at higher points of the map. What if you want a river or like running on a cliff above the water level or want to have a waterfall? It rather limits what the maps can look like. _________________
Quote:
This is sexier than what this forum was supposed to tolerate. - Banshee
AFAIK D3D is pretty much same as OpenGL here. (on the other hand, I'm not very advanced OpenGL programmer- I never used more texture passes)
I can say that I don't like engines with huge colormap+one same detail map everywhere, though.
If meshes for water, there could be colliding meshes too (to allow overhangs for instance, could be used for bridges too.) Deformation of these would be a bit tricky if you wanted anything more than TS bridge destruction, however. _________________ Time will tell...
Sooner or later...
Time will tell... QUICK_EDIT
Joined: 22 Aug 2006 Location: somewhere south of the north pole
Posted: Sat Jun 30, 2007 5:41 pm Post subject:
I have an idea:
Use two images, with different terrain, and different colors, it's an workaround, but not perfect, waterfalls would be rather hard to do... But, it's one way do do it _________________ This is a signature QUICK_EDIT
Since OTS is going to include terrian deformation - I am wondering about the strategic value of the gameplay. Since it is going to have more freedom then the original TS in terms of terrain, could we include some units that are able to have the sole purpose of modifying terrain (e.g. building tunnels, diverting water from a river / ocean to cut off an enemy or get across) and superweapons that cause earthquakes that can tear cracks through the ground to block off access etc. This is probably looking too far ahead of time, but I think it will add an extra dimension to the gameplay mechanics - giving the gamer the ability to highly modify the terrain for their needs.
On a crazy note:
I was thinking of OTS having a superweapon, such as a subterranean nuclear 'torpedo', that NOD uses; A nuclear 'underground' warhead. The opposing GDI player places seismic sensors around the place that can detect an incoming torpedo, and the GDI player can use their earthquake superweapon to take out the incoming torpedo or they could get a unit to dig a 'trench' around their base and divert water into it, which would make the torpedo ineffective..
On another note, NOD can use special metal platforms with supports that can handle small shifts / shears in the terrain, which they build their base onto. This helps prevent GDI's earthquake superweapon from doing much damage - however if a too larger crack forms the platform with the buildings / units on it fall into it. Also the platform will incur some damage per earthquake - but minor. Also a rule such as the earthquakes are not as effective on high terrain points could exist.
GDI can use sensors, in conjunction with their earthquake superweapon or terrain mod to counter NOD's torpedo superweapon attack.
NOD uses technology - special platforms - to counter GDIs earthquake superweapon attack. The plaforms should be moderately priced. The GDI player should use their superweapon to take out a horde of units or 'unsupported' NOD bases.
These ideas are based around the player being able to get in 'touch' and being able to use the terrain to their advantage. These are just some additional superweapons (other then ion cannon / missle) to make it more fun. QUICK_EDIT
Since OTS is going to include terrian deformation - I am wondering about the strategic value of the gameplay. Since it is going to have more freedom then the original TS in terms of terrain, could we include some units that are able to have the sole purpose of modifying terrain (e.g. building tunnels, diverting water from a river / ocean to cut off an enemy or get across) and superweapons that cause earthquakes that can tear cracks through the ground to block off access etc. This is probably looking too far ahead of time, but I think it will add an extra dimension to the gameplay mechanics - giving the gamer the ability to highly modify the terrain for their needs.
On a crazy note:
I was thinking of OTS having a superweapon, such as a subterranean nuclear 'torpedo', that NOD uses; A nuclear 'underground' warhead. The opposing GDI player places seismic sensors around the place that can detect an incoming torpedo, and the GDI player can use their earthquake superweapon to take out the incoming torpedo or they could get a unit to dig a 'trench' around their base and divert water into it, which would make the torpedo ineffective..
On another note, NOD can use special metal platforms with supports that can handle small shifts / shears in the terrain, which they build their base onto. This helps prevent GDI's earthquake superweapon from doing much damage - however if a too larger crack forms the platform with the buildings / units on it fall into it. Also the platform will incur some damage per earthquake - but minor. Also a rule such as the earthquakes are not as effective on high terrain points could exist.
GDI can use sensors, in conjunction with their earthquake superweapon or terrain mod to counter NOD's torpedo superweapon attack.
NOD uses technology - special platforms - to counter GDIs earthquake superweapon attack. The plaforms should be moderately priced. The GDI player should use their superweapon to take out a horde of units or 'unsupported' NOD bases.
These ideas are based around the player being able to get in 'touch' and being able to use the terrain to their advantage. These are just some additional superweapons (other then ion cannon / missle) to make it more fun.
woah, easy there, we want to keep the game the same, and only update the engine and graphics _________________ Micro TS
Portable, no campaign, movies or music, just the engine and needed resources for skirmish and lan. QUICK_EDIT
I think terrain deformation units should be in (later), but only for modders. Earth 2150 had exactly this type of unit, and it was great, altough pretty buggy in that game (the unit dug a trench, and couldn't get out of there) _________________ Time will tell...
Sooner or later...
Time will tell... QUICK_EDIT
I suggest to make a 'abstract graphic layer'
so that OTS will support both OpenGL and D3D because Microsoft's WinXP default graphic card driver do not support OpenGL & it will run in software rendering mode & in a very low speed(1 fps), some people will not be able to run OTS unless they've installed the driver which came from the graphic card's productor.
you may want to do this in the future & at that time it is hard to change because the engine is too complex and have too many OpenGL API references.. I've suffered from these kinds of problems.
Making a 'abstract graphic layer' means to make rendersystems for different APIs, which is a lot of work. QUICK_EDIT
I suggest to make a 'abstract graphic layer'
so that OTS will support both OpenGL and D3D because Microsoft's WinXP default graphic card driver do not support OpenGL & it will run in software rendering mode & in a very low speed(1 fps), some people will not be able to run OTS unless they've installed the driver which came from the graphic card's productor.
you may want to do this in the future & at that time it is hard to change because the engine is too complex and have too many OpenGL API references.. I've suffered from these kinds of problems.
Making a 'abstract graphic layer' means to make rendersystems for different APIs, which is a lot of work.
It would really be too troublesome to implement, I think it's also safe to assume people will install the proper drivers. I won't stand for people being lazy. _________________ Micro TS
Portable, no campaign, movies or music, just the engine and needed resources for skirmish and lan. QUICK_EDIT
Joined: 26 Nov 2002 Location: Algae Colony On Mars
Posted: Wed Jul 11, 2007 11:53 am Post subject:
The people who only have the preinstalled graphics driver installed aren't the people who will play this mod. I don't see why OpenGL should be ignored because of Microsoft's attempts to force DirectX on the population. _________________
Quote:
This is sexier than what this forum was supposed to tolerate. - Banshee
Joined: 08 Jul 2006 Location: in your closet... Post = true
Posted: Wed Jul 11, 2007 8:28 pm Post subject:
About the Terrain-deformation. Is it possible to have the terrain "regenerating" slowly to its former state? Its just because that players might use abit too much of their land-deforming weapons from time to time so that elemental parts of the map may become un-usable and un-passable. Same goes for the space the players were supposed to build their bases on.
If that is just not possible - theres nobody forcing you to implement deformable maps. I never cared about that when I played TS, and I havent cared when I played Warhammer 40K an hour ago. _________________ audiopulse sagt:
your raging arse is creating storms?
Luke | CCHyper sagt:
yup, neptune size! QUICK_EDIT
Joined: 08 Jul 2006 Location: in your closet... Post = true
Posted: Wed Jul 11, 2007 10:31 pm Post subject:
Maybe, but then again it may happen that the maps look like crap, after a hard match. The units may help in some case, but they may make it look even worse.
Regenerating terrain would provide all usage of deformable terrain, but ensure that the map would at least become usable again, after a certain amount of time.
Youre right, having Craters shrink sounds weird, but i haven thougt of them beeing all disappeared after two minutes, but maybe after 20-30 minutes? Gaps are about to fill up themselves due to the heavy vibrations that must occur from time to time on a battlefield by detonations, craters are ironed out due to vehicles and troopse driving over...
You may also give that as an option to turn on or off, or let modders code that feature into their maps.
...unless this is possible, of course. _________________ audiopulse sagt:
your raging arse is creating storms?
Luke | CCHyper sagt:
yup, neptune size! QUICK_EDIT
Even D3D runs pretty slow without drivers (please don't call that thing from M$ a driver)
All gamers I know have their GPU's drivers, only the people who don't concentrate on games and play some sort of an arcade once in a time don't have them. I don't think an abstraction layer is a bad idea, but it takes _time_ to do. Also, if you don't use API's specific data types (GLfloat, etc.), it's possible that your code will become uncompatible with it in future (although not any soon)
Also, even if you had an abstraction layer, it would take even
_more time_ to write a D3D renderer. And if you want compatibility, you should want CPU independent SW renderer instead . (which isn't that impossible with multicore processors, btw) _________________ Time will tell...
Sooner or later...
Time will tell... QUICK_EDIT
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
)
But, it's one way do do it 
