Sign in to follow this  
Halsafar

Improve alpha map resolution on one buffer terrain

Recommended Posts

The subject says it all. I have a one DIP call terrain. I wish to use one alpha map stretched over it but at current it looks like this: 513x513 heightmap scaled by 100 into vertices (0 - 5130) the largest texture possible, 512x512 results in 1pixel/100 texels. How can I avoid this?

Share this post


Link to post
Share on other sites
I cannot possibly tile the alpha map.
The alpha map has certain regions shaded to match the terrain's height and to mask certain textures in certain area's. It can only be tiled once.

Share this post


Link to post
Share on other sites
Well I got texture splatting working fine.
It has been incorporated into my engine.

Now it is a matter of solving what this subject claims.


I have to loose some fps and render terrain chunks with seperate DIP calls.
Or
I can find a way to increase alphamap resolution without tiling it. (read the first post)

Share this post


Link to post
Share on other sites
Either way, the only way to increase the alpha map resolution is to do just that -- increase the resolution. This is done either by enlarging the alpha map for that one giant zone for the entire terrain, or by splitting up the terrain into zones, each with its own alpha map. Both of these increase the effective terrain alpha map size. Splitting into zones also will help collision detection (especially ray casting) down the road.

I wouldn't worry about losing fps with multiple DIP calls. It's better than sending half a million triangles to the card just for the terrain, especially if you add multiple ground-type texture layers where it ends up requiring more than one pass (I've used up to 7 layers in one area).

Where did this "1pixel/100texels" thing come from though? I presume you mean 1 texel per 100 units.

Share this post


Link to post
Share on other sites
....ugh

My terrain is already in a quad-tree, it is also being frustum culled. It is also being rendered in a single buffer, which means one DIP call. The only expensive part of the operation is when a node memcpy's its vertices into the vertex buffer.

A texel in a texture pixel as it is mapped into the hardware.

For each pixel in the alpha map 100 texel's will use the point for its alpha blend. 513x513 heightmap, scaled by 100 to vertices, thus 5130x5130. The largest texture possible on most cards is 512x512, thus leaving me with an exact ratio of 1 alphamap pixel to every 100 texels.


Multiple DIP calls are ineffecient but it seems the only way.

I was pondering a way where I could send 4 alpha maps and 4 textures, each of the 4 alphamaps could represent the 4 most outer quad tree nodes. That would then give me a 1/50 ratio, but that is still pretty bad.

I need a 2/1 ratio, 2 pixels for every 1 texel...

Share this post


Link to post
Share on other sites
Quote:
Original post by Halsafar
....ugh

My terrain is already in a quad-tree, it is also being frustum culled. It is also being rendered in a single buffer, which means one DIP call. The only expensive part of the operation is when a node memcpy's its vertices into the vertex buffer.

A texel in a texture pixel as it is mapped into the hardware.

For each pixel in the alpha map 100 texel's will use the point for its alpha blend. 513x513 heightmap, scaled by 100 to vertices, thus 5130x5130. The largest texture possible on most cards is 512x512, thus leaving me with an exact ratio of 1 alphamap pixel to every 100 texels.


Multiple DIP calls are ineffecient but it seems the only way.

I was pondering a way where I could send 4 alpha maps and 4 textures, each of the 4 alphamaps could represent the 4 most outer quad tree nodes. That would then give me a 1/50 ratio, but that is still pretty bad.

I need a 2/1 ratio, 2 pixels for every 1 texel...


Yes, I understand your "pixel/texel" arrangement independent of whatever naming convention you're using -- didn't need the definition of texel (even though it's just a texture element regardless of if it's being "mapped into hardware" or not)

Multiple DIP calls are not inefficient if you control the batch size properly. In fact, I'd sooner call DIP a few times rather than try and drop 40k triangles worth of vertices with memcpy. That way, I could stay over 500fps.

Why isn't it feasible to increase the alpha map size to 1024 or even 2048? The largest texture on most cards exceeds 512..

Share this post


Link to post
Share on other sites
It seems the point of dumping 40k triangles at once has been made twice....

In any scenerio, 40k triangles for the terrain at once is too much.
At most I probably run around 1k triangles, probably less.
Using one buffer for that is FAR faster than using one buffer for each bit of triangles in a node.


The resolution could be 1/1, that would be perfect.
I haven't had much time the past few days, no programming has been done. I'll be altering the terrain engine with a few tweaks, shouldn't take no more than 10 minutes and I'll have it set up with multiple buffers, which is wut I want to avoid.


The max on most older cards are 512x512.
My card happens to support 2048x2048, I suppose that would get me a 1/25 ratio...hmmm.

Share this post


Link to post
Share on other sites
40k is too much? Who has the say in what's too much?
Chalk that up to somebody saying that nobody would need more than 640kb of memory. Multiple passes for layering or other techniques can push 40k.

And can you prove that memcpy'ing random strips of vertices from one buffer to another is actually faster than calling DIP on maybe 5 or 6 different buffers.. all of which most likely already reside within the memory on the video card itself still (rather than having to retrieve a new memory block/dma & re-upload it every frame)?

It may be possible that it's "fast" because you're using such a huge XZ scale for vertices and are copying so few actual vertices, but I can't see that having any natural fidelity. What's your typical batch size?

I haven't heard of a card having a texture limit size of 512x512 for a long, *long* time. Even a GF3 Ti200 has a max texture size of 4096x4096. though limits for 3D textures of 512x512x512 still exist. However, that's huge anyway.

So we're left with your original problem. You're either stuck with increasing the resolution of the alpha image, splitting the possible 4 channels of it into 4 sections of mapped terrain (creating a need for a pixel shader to unsplit it.. which rules out any limit of 512 sized textures anyway), or making more than one DIP call.

more than one DIP call (especially since you've got such a huge scale, you'll only call it probably a maximum of 2 or 3 times in a frame) is NOT going to hinder your performance.

Share this post


Link to post
Share on other sites
DIP will be called once for every node in the view frustrum.

Who says thats to much.... Hardware does... Good luck rendering 40k tri a frame just for your terrain and expect to get GameLogic in there.

I realize I hit 20k at the worst times. Cuz i'm using sphere-frustrum planes. I should use AABB-plane for accuracy.

Share this post


Link to post
Share on other sites
Good luck? Absolutely no problem with it.

I push atleast 40k/frame and still maintain over 400fps (66GTOC, 2.8C). Hardware does not dictate that a small number of DIP calls with an efficient batch size is "too much".
Usually, I nail about 25MTri/sec just for the terrain itself sending 2k batches of triangles per DIP call. MS recommends about 1k per batch in the Direct3D docs about performance optimization. I use a XZ scale of 4 to maintain atleast some form of visual quality, but that's just because it generally has lots of small hills and ditches (think: a BattleField2 map).

Considering your maximum texture size of 512, and that you seem to think 40k of triangles/frame bottlenecks the app completely, I would be led to believe you're developing on really old hardware (maybe a matrox mystique). In this, I still don't see how memcpy could possibly be faster than switching buffers already resident in video memory. If numbers & source can be provided, or an actual technical explanation by a MVP comes around, that could clear it up. Until then, the options have been laid out.

[Edited by - sordid on July 1, 2005 3:35:40 PM]

Share this post


Link to post
Share on other sites
You are making very good points.
If MS docs it by saying 1k batch's are fine I tend to believe MS.
I'd like to hear what Nvidia or other repsectable card companies have to say about it.


As for the hardware I am working on...
2.8GHZ P4, 512MB RAM, 128MB GPU (onboard).


Unfortunately the game I am making will be mostly played by my friends I assume and some people on the internet. I'd like to avoid having to stamp the above hardware specs as the minimum requirements. So I am assuming its goona be played on a 16MB Video cards or higher.

A further unfortunate piece of the puzzle fell into place this morning. I am using a PS1.4 to texture splat. That successfully eliminated ALL my friends comps from playing the game. So I checked, they can single-pass multitexture but I don't think it is possible to texture splat in single pass'

Share this post


Link to post
Share on other sites
Is it because you're using the same texcoords for two different texture samplings?
Would it be possible to post the shader code?

I had the 1.4 requirement when I sampled two textures using the same texcoords.. solved this (ugly, however) through creating another texture coord in the vertex shader out to sample another texture with.

Of course, I was using HLSL.


What exactly is requiring 1.4 in your code?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this