Sorry your browser is not supported!

I seem to be posting a lot of newbie questions of late.

Here's the latest:

I'm working with a 3x3 grid of terrain objects, each object is a simple high poly plain constructed using the Matrix1 utilities. I'm experimenting with using a shader to create the heights of the terrains from 9 separate but related heightmap images. That part of the system works nicely - apart from some ugly seams between some of the 9 segments. As a diagnostic aid I've created a small test object which is intended to move around the surface of the terrain. The baffling thing is that it does for 3 of the bitmaps but not the others. The heightmaps, bitmaps and objects are currently laid out in the same order as shown below:

123
456
789

Since the terrain heights are produced in real time using a shader, I cannot use the intersect object command to place the test object just above the terrain. Instead, I've been doing a bitmap read from the relevant heightmap as the test object moves around. The attached demo using just a single map segment illustrates the basic idea. [Connoisseurs of advanced terrain might recognize the terrain map .]

Anyway, the problem concerns my attempt to extend this to several objects and their associated maps. In my current version, the relevant bitmap is correctly identified while the test object moves over different segments. The only thing that is obviously wrong is the reported pixel value of the relevant heightmap - they are always reported as zero for certain of the maps when I try to access them in real time. The others work perfectly. The maps themselves are fine - I've tested them, in real time again, by doing a get image and pasting that to the screen. In each case the map is pasted perfectly (even if it is the wrong map). The lines that are failing are the following:



I am completely baffled. I wondered if it was a DBPro version problem or perhaps a machine issue - however I get identical results on two different machines and with two different versions of DBPro (DBPro9Ex and U7RC7).

Any suggestions where I should look next?

Edit: removed ineffective colour tags from line 3.

Correction!!

The error is in the calculation of the bitmap coordinates testX and testY - they are consistently wrong in the problem regions of the map. Not sure why for now but at least I know where to look next . Here is the relevant bit of code:



It's the second half of the two main if/else constructs that is not being activated correctly so I'm getting values in excess of the bitmap width which, in turn, means that the pixel lookup returns zero. It's probably a silly error which will become apparent as soon as I put some test numbers in . I'll report back later.

It's been a while since I did any serious debugging - and it shows.

When I've dealt with this I can sort out the seams.

Correction again

I need my sight tested!! I've used "textX" and textY" in the second half of those if/else blocks. They should be "testX" and "testY"!!

That was painful! Serves me right for switching between HLSL where everything needs to be declared, and DBPro where it doesn't.

Thanks for checking this anyone.

Here's a screenshot from a "proof of concept" demo showing part of the 3x3 grid in action. This is simply using the green-scale heightmap to colour the terrain - but as you can see there are small, but noticeable seams between the segments. I know why they are there and have a plan to remove them, so that will be the next stage of this particular project. The 9 heightmaps used here were prepared using my Perlin noise shader posted a while back.

The overall aim is to have an endless terrain which is being continually recreated, in a reproducible manner, using shaders as you explore it. By using a shader to render the vertex heights, and another to generate the segment heightmaps as required, I can dispense with a lot of the CPU performance hungry activities normally associated with setting up each terrain segment. Modern GPUs have tremendous underused potential.



.

Looks good man. I was working on a similar 3x3 grid system years ago with advanced terrain and the vertexdata commands, I was never quite able to get rid of all of the seams and performance wasnt great, I think your approach with vertex shader and matrix1 grid looks a lot more promising.

Very true; the only problem left to solve now are the programmers like me; not much potential.



It would make for a great ocean shader too, with a little bit of animation.

The one issue I have with that is if you were to really use this for animated water like an ocean, then what are you going to do when you want reflection/refraction/lighting effects? From what I understand you sort of need to dig in real deep and implement a shader that merges all of those things with this animated mesh thing. Maybe you'll mention an easy or trivial way around this problem. Like maybe I am overlooking you can just stack effects in some way. However this always struck me as something that hamstrung people using DBPro with shaders. You use the lighting shader but that odd thing using a fur shader ignores all of the lighting, etc. So you can't really get around becoming a Rembrandt with the shader language.

You don't really need to be a Rembrandt or even a wizard ( ) - just need the patience to learn how to combine such effects in an orderly manner. Much like programming generally really - you need good documentation and/or people willing to help out. There are quite a few around on this forum thankfully. Good documentation for shaders still seems to be hard to find though, especially for the earlier versions SM1, SM2 and SM3 required by DBPro (I'm not sure about the present status of the DX11 version that Rudolpho was developing a while back which I think supported SM4 and possibly SM5 ).

The MS site has all the information you need, but somehow fails to tell you how to use it - and their old demos don't seem to be easily accessible anymore . Also, the MS docs seem to switch in some confusing way between telling you about HLSL one minute and then ASM the next - most shader programmers these days, including me, are OK with HLSL but not with ASM code. Same applies to the nVidia site which used to have a collection of shader demos that you could play with and adapt for your own purposes.



Evolved did that in an early version of Advanced Lighting but I think he's gone down a different route in his more recent versions.



Thanks. I hope to have some better looking demos available soon. This is a project that I've had on a back-burner for a long time and finally seem able to get it moving along. The basic idea is that the "terrain" is nothing more than a small grid of simple high-poly plains (I've chosen 3x3 for simplicity at this stage - but may need to step up to a larger grid at some stage to get sufficient resolution in the mesh shape). That's all you need - just those few plains. All the work is done by the shader (plus usual "housekeeping" and game logic on the CPU of course) as you move around. For example, starting from an initial grid of 9 plains, the "player" would start in segment 5:

123
456
789

The player might then move to an adjacent segment, segment 3 for example. To maintain the visuals of the terrain, the program would need to either rearrange the original grid to something like the following (green indicates the new segments which need heightmaps to be recalculated, red indicates the segment currently occupied by the player)

897
231
564

or, possibly simply use the original layout with new heightmaps where necessary and the original ones for segments 2,3, 5 and 6, moved around, etc. I haven't decided which route is simpler yet - both would need the new segment images to be computed (but that can be done virtually instantly on modern GPUs). The question really comes down to which leads to simpler housekeeping as you move around the terrain. Watch this space I suppose.

Very true. I've done something similar in the past; but I have to admit that I only recently discovered per vertex texture lookups in Shader model 3 which is what Green Gandalf is using.

The vertex shader function animated (and in some-cases applied lighting and provide reflections in the case of per vertex rendering), and the pixel function would apply the lighting , refraction and reflections with unnoticeable impact on performance.

The potential overhead with this kind development is collision detection. What does one do to handle raycasting and physics on geometry defined on the GPU?

That is the main difficulty. As far as the terrain is concerned all you need is the heightmap as in my demo earlier. Most other objects would be handled in the usual way. One difficulty is how to deal with things like roads or trails in the wilderness where you would probably want to modify the terrain's vertex heights slightly. That could be handled in a similar way by having a separate render for the final version of the heightmap and use that for calculating heights and collision on the CPU. Sounds doable to me if somewhat messy.

Anyway, let's see how things develop - there's usually more than one way to skin a cat.

I was thinking of another way to skin the cat; considering that even dated GPUs capable of billions of calculations per second, if for some reason it were not convenient to have to use CPU pixel functions for collision, or if it were not convenient to expose the height field result to the CPU, we would be to use shader constant value retrevals using the jGFX plugin. The Shader_GetFloatVal() function could return the distance of an entity from the closest vertex, and the maximum elevation of its location and the floor.

It seems from my perspective to be quite a challenge to be able to produce LIMITLESS roads or trails baked to a texture, with the constraints on texture memory. Should not be an issue with clever texture management though.

But if for some reason one wanted to define roads and trails as vectors; these could be rendered based on the distance and angle of each vertex/point, in relation to each point along road path defined as a polygon or bezier curve array.

I digress.

Indeed. It's early days yet though - and I won't be able to do much on this today . Hopefully I'll have another prototype working by the end of the week.

Thanks for the suggestions, I'll look into them.

Ortu said:



I said:



Well, that plan worked . Here's a new screenshot. I couldn't see any seams when I explored the terrain more carefully. I think a variation of the same method will enable me to get decent seamless normal maps to replace the usual vertex normals. Then standard colour maps and bump maps can be added in the usual way. That will be the next stage.