Re: Map Drawing
Posted: 12 May 2008, 03:41
So...
Could you use this for day/night maps?
That would be sweet for mods (a.k.a. CA
)
Could you use this for day/night maps?
That would be sweet for mods (a.k.a. CA
)Page 2 of 3
Re: Map Drawing
Posted: 10 Jun 2008, 04:55
Sorry to ask, but I'm not a mapper. What exactly could this do? Are we talking random map generator, or just a faster way to download map info, or something else entirely?
Re: Map Drawing
Posted: 11 Jun 2008, 17:03
The project was to use it to increase detail in maps by using some texture layers with normal maps and alpha channels.
But now it works like a lua map drawing, or a lua map format.
Currently it uses normals, but no alpha, and i am working on a bunch of algorithms to automatically texture the map.
This could also be used for effects like fog of war.
but about the height map, it would be harder, but there are a lot of algorithms for that.
Probably yes.
But now it works like a lua map drawing, or a lua map format.
Currently it uses normals, but no alpha, and i am working on a bunch of algorithms to automatically texture the map.
More detailed maps, allow using alpha channels in the map texture, maybe even reflective map textures.Aztek wrote:What exactly could this do?
This could also be used for effects like fog of war.
Maybe, generating a random map texture wouldn't be a big problem,Aztek wrote:random map generator
but about the height map, it would be harder, but there are a lot of algorithms for that.
url_00 wrote:Could you use this for day/night maps?
Probably yes.
Re: Map Drawing
Posted: 11 Jun 2008, 20:43
Ok what's an alpha channel?
Re: Map Drawing
Posted: 11 Jun 2008, 21:10
The fourth channel of an image, like:Aztek wrote:
Ok what's an alpha channel?
RGBA
R red
G green
B blue
A alpha
Alpha is the transparency of an image, 0 alpha means it is completely transparent.
Most images only use the first three channels.
Re: Map Drawing
Posted: 11 Jun 2008, 22:23
Ah ok thanks man.
Re: Map Drawing
Posted: 12 Jun 2008, 01:36
I will post here some screen shots of all the progress done.
1.
2.
Both are using normals, the first is smooth shaded, no texture, the map is small divide, using 8x8 quads.
The second uses texture, smooth shaded, 32x32 quads, it uses the alpha channel.
It is much faster than the old one.
1.
2.
Both are using normals, the first is smooth shaded, no texture, the map is small divide, using 8x8 quads.
The second uses texture, smooth shaded, 32x32 quads, it uses the alpha channel.
It is much faster than the old one.
Re: Map Drawing
Posted: 12 Jun 2008, 01:55
That's extremely interesting. Does it use GLSL yet? And is there any way to shut off the standard map renderer, so that speed's comparable? And how is it handling culling of elements from the POV?
Re: Map Drawing
Posted: 12 Jun 2008, 08:53
This makes me ... very, comfortable.
Re: Map Drawing
Posted: 12 Jun 2008, 17:14
It already does, Spring.SetDrawGround(false)Argh wrote:And is there any way to shut off the standard map renderer
At 32x32 or 16x16 it as fast as the standard map renderer, but performance has been tested quite few times.Argh wrote:so that speed's comparable?
There is a big problem on textures, that i will need some help to fix, it causes the texture to be rendered incorrectly or something like that, i will post a screen shot soon.
Re: Map Drawing
Posted: 13 Jun 2008, 00:45
Here:
3. Wrong(in game):
4. Right(in the image editor):
And here is some code:
I spent hours trying to fix it, no good results.
3. Wrong(in game):
4. Right(in the image editor):
And here is some code:
Code: Select all
gl.Color(r3,g3,b3,a3)
gl.Normal(Spring.GetGroundNormal(xx+d,zz+d))
gl.Vertex(xx+d,H(xx+d,zz+d,d*0.5),zz+d)
if (tiledtex == true) then gl.TexCoord(0,1)
elseif (tiledtex == false) then gl.TexCoord(x/(mx/d),(y+1)/(mz/d)) end
gl.Color(r2,g2,b2,a2)
gl.Normal(Spring.GetGroundNormal(xx ,zz+d))
gl.Vertex(xx,H(xx,zz+d,d*0.5),zz+d)
if (tiledtex == true) then gl.TexCoord(0,0)
elseif (tiledtex == false) then gl.TexCoord(x/(mx/d),y/(mz/d)) end
gl.Color(r1,g1,b1,a1)
gl.Normal(Spring.GetGroundNormal(xx ,zz ))
gl.Vertex(xx,H(xx,zz,d*0.5),zz)
if (tiledtex == true) then gl.TexCoord(1,0)
elseif (tiledtex == false) then gl.TexCoord((x+1)/(mx/d),y/(mz/d)) end
gl.Color(r4,g4,b4,a4)
gl.Normal(Spring.GetGroundNormal(xx+d,zz ))
gl.Vertex(xx+d,H(xx+d,zz,d*0.5),zz)
if (tiledtex == true) then gl.TexCoord(1,1)
elseif (tiledtex == false) then gl.TexCoord((x+1)/(mx/d),(y+1)/(mz/d)) endRe: Map Drawing
Posted: 16 Jun 2008, 17:07
Would this, for example allow us to overlay custom detail textures based on the typemap?
Re: Map Drawing
Posted: 12 Jul 2008, 23:32
Uploaded this current version:
get it here
The zip file contains the textures i used on these cool screens too.
And i think i have not been clear enough about why this is taking so long, i will explain it again:
I don't know how to fix that texture issue, so please, i will need some help.
And i made a really cool thing using a "copy" of the algorithms in this script, that maybe would allow day to night cycles.
get it here
The zip file contains the textures i used on these cool screens too.
And i think i have not been clear enough about why this is taking so long, i will explain it again:
I don't know how to fix that texture issue, so please, i will need some help.
And i made a really cool thing using a "copy" of the algorithms in this script, that maybe would allow day to night cycles.
Re: Map Drawing
Posted: 13 Jul 2008, 12:39
Hmm looks interesting.
I'll try to fix it. However, Lua code like this is really difficult for non-author to read, given the habit of defining local names for all global things.
Also... this thing just makes gl list with no LOD or frustum culling... this might be faster on modern cards than spring's LOD code. However, for me, it is about 2x (or more) slower.
Spring's map drawing draws map with varying detail depending to distance from point of view; and AFAIK discards blocks outside of the view. This is relatively CPU intensive operation, probably better done in C++ rather than Lua ; additionally, C++ has benefit of static type and error checking.
Furthermore, drawing quad strips is faster operation than drawing individual quads.
In C++ you can use for example Color and Vector types with overloaded operators, which results in shorter, easier to maintain, less buggy code.
I'll try to fix it. However, Lua code like this is really difficult for non-author to read, given the habit of defining local names for all global things.
Also... this thing just makes gl list with no LOD or frustum culling... this might be faster on modern cards than spring's LOD code. However, for me, it is about 2x (or more) slower.
Spring's map drawing draws map with varying detail depending to distance from point of view; and AFAIK discards blocks outside of the view. This is relatively CPU intensive operation, probably better done in C++ rather than Lua ; additionally, C++ has benefit of static type and error checking.
Furthermore, drawing quad strips is faster operation than drawing individual quads.
In C++ you can use for example Color and Vector types with overloaded operators, which results in shorter, easier to maintain, less buggy code.
Re: Map Drawing
Posted: 13 Jul 2008, 13:28
http://pastebin.com/f1c669bec
Fixed it, texture works correctly now. I'll pastebin "optimized" version later.
Not to discourage innovation, but i would hate if functionality implemented in maintainable C++ would be replaced by such Lua scripts, rather than fixing/updating existing code. This script is drastically slower than spring's map rendering (for me), even though spring does lot more stuff with maps. It is also less maintainable. On optimization side, it is pretty much as bruteforce as map rendering could ever be; no LOD, no frustum culling, not even using quad strips.
By the way. *What the hell* is " if a==true then elseif a==false then end" ? Shouldnt that be "if a then else end" ? or theres some Lua quirk I'm not aware of?
(I hope having fixed this thing gives me some right to criticize. Also, I'd like those whom don't fully understand the fix to refrain from making posts in that thread until understanding, even if that takes long while)
Fixed it, texture works correctly now. I'll pastebin "optimized" version later.
Not to discourage innovation, but i would hate if functionality implemented in maintainable C++ would be replaced by such Lua scripts, rather than fixing/updating existing code. This script is drastically slower than spring's map rendering (for me), even though spring does lot more stuff with maps. It is also less maintainable. On optimization side, it is pretty much as bruteforce as map rendering could ever be; no LOD, no frustum culling, not even using quad strips.
By the way. *What the hell* is " if a==true then elseif a==false then end" ? Shouldnt that be "if a then else end" ? or theres some Lua quirk I'm not aware of?
(I hope having fixed this thing gives me some right to criticize. Also, I'd like those whom don't fully understand the fix to refrain from making posts in that thread until understanding, even if that takes long while)
Re: Map Drawing
Posted: 13 Jul 2008, 14:15
A bit presumptious for what the fix amounts to (specifiying the texcoorsAlso, I'd like those whom don't fully understand the fix to refrain from making posts in that thread until understanding, even if that takes long while)
in non-tiled mode in the same order as the vertices), don't you think?
Re: Map Drawing
Posted: 13 Jul 2008, 14:26
I wouldn't say that if fix was complicated. (T.B.H. I'm sick of especially Argh's comments on this forum. Not hard to predict that coz i basically said that LUA map drawer is bad idea, a lot of ppl gonna jump in)Kloot wrote:A bit presumptious for what the fix amounts toAlso, I'd like those whom don't fully understand the fix to refrain from making posts in that thread until understanding, even if that takes long while)
Naw, you also didn't see the real bug in the code(specifiying the texcoors
in non-tiled mode in the same order as the vertices), don't you think?
Of course it would take no time for user to fix vertice order...
Re: Map Drawing
Posted: 13 Jul 2008, 14:38
I meant that the corners of the quad were out of phase with the
texcoords, bottom-right vertex mapping to bottom-left TC etc. It
just seemed like a strange thing to say "stay out unless you get
this".
texcoords, bottom-right vertex mapping to bottom-left TC etc. It
just seemed like a strange thing to say "stay out unless you get
this".
Re: Map Drawing
Posted: 13 Jul 2008, 14:45
Thanks for the help.
This script will never draw awesome maps faster than the spring map renderer, the only thing it will allow is features that currently the spring map renderer doesn't has.
For me it is still playable at 16x16 detail.This script is drastically slower than spring's map rendering (for me), even though spring does lot more stuff with maps.
Probably it is, because lua is much slower, and it lacks many useful features.LUA map drawer is bad idea
This script will never draw awesome maps faster than the spring map renderer, the only thing it will allow is features that currently the spring map renderer doesn't has.
Re: Map Drawing
Posted: 13 Jul 2008, 14:55
well the real bug is that you need to set all vertex properties (including glTexCoord) before call to glVertex . This code called glTexCoord after glVertex , specifying the texture coordinate of entirely different vertex.Kloot wrote:I meant that the corners of the quad were out of phase with the
texcoords, bottom-right vertex mapping to bottom-left TC etc. It
just seemed like a strange thing to say "stay out unless you get
this".
user: hows about updating existing code, rather than reinventing wheel, especially a triangular shaped wheel?
You only could get comparable FPS with your renderer and spring's because spring's renderer does a lot more stuff (like trees on smalldivide, multiple textures, etc), and only when zoomed out. Its really very easy to draw a bunch of quads into display list (and corresponding c++ code is shorter and more readable, as it could use vector and color types with operators). The hard part is level of detail, frustum culling, etc. Maintainability wise, it is really bad. Lua hacks for everything, given the Lua coding style (and poor maintainability by different developer) could be the killer of spring.