Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / memblock terrain, how to make one?

Author
Message
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 22nd Nov 2007 23:44
I've heard about memblock terrains but haven't come across anything on how to create one.

I did a search through the board for "memblock terrain" but the only threads I got were asking about it AFTER making it.

Can someone point me in the direction of how to create a memblock terrain, please?


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
TEH_CODERER
20
Years of Service
User Offline
Joined: 12th Nov 2003
Location: Right behind you!
Posted: 23rd Nov 2007 00:34
Take a look at these two threads.
http://forum.thegamecreators.com/?m=forum_view&t=87105&b=7
http://forum.thegamecreators.com/?m=forum_view&t=87081&b=7
It is best with memblocks to try to understand for yourself because once you get the hang of them they are quite simple. However, if you get completely stumped then I'll help you out.

Your signature has been erased by a mod - image max size is 600x120
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 23rd Nov 2007 04:35
Okay, I'm not COMPLETELY stumped on this... I would just like to know if you can think of a quick way to make a terrain using memblocks that would allow me to individually texture tiles... it's kinda crucial for my project.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
TEH_CODERER
20
Years of Service
User Offline
Joined: 12th Nov 2003
Location: Right behind you!
Posted: 23rd Nov 2007 12:15
Well I learnt everything I know about memblock meshes from those two links. When adding vertices, you set their position, normals and UV data. Its the UV data that you want to look at as this determines how textures are mapped onto the object.

Your signature has been erased by a mod - image max size is 600x120
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 23rd Nov 2007 21:25
Okay, but I'm trying to figure out a more efficient way of doing this. In my project, I'm finding myself needing to use dynamically created textures on individual tiles of the terrain.

In the example, the image is applied directly to the object that is created from the memblock. I can't do that, since I want each tile to use a seperate image.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 23rd Nov 2007 21:42
@Plystire
You put all the tile images into a grid, to form one large image, you then texture your memblock terrain with that image. To set which tile displays which image tile, just modify the UV data for that tile to match where the image is in the grid (UV values range from 0-1 where 0 is the left or top of the image and 1 is the bottom or right of the image).

TEH_CODERER
20
Years of Service
User Offline
Joined: 12th Nov 2003
Location: Right behind you!
Posted: 24th Nov 2007 01:11
As Diggsey says. I would've helped more but I always find that I get a better grasp of stuff when I work it out myself.

Your signature has been erased by a mod - image max size is 600x120
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 24th Nov 2007 06:23 Edited at: 24th Nov 2007 08:05
Okay, here's the problem with that method...

I technically have an unlimited number of images that I want to be able to use on the terrain, because the engine "creates" new images from a template during runtime and I want to be able to use all those dynamically created images on the terrain.

So, you see, I can't just make one really big image to use on the terrain, since I technically don't know what that image would look like ahead of time, it's created by my game while it's running.

[EDIT]
Correction: not "unlimited" potential images... only about 800 potential 256x256 images.

Now, would I even be able to have an image large enough to hold all 800 potentials? If not, would I be able to store all 800 into 800 different DBP images and then be able to take an individual image and texture it to an individual tile in the terrain object?

Or, if worse comes to worse would I need to size down my desired image resolution and maybe size down the number of potentials?
[/EDIT]


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 24th Nov 2007 09:53
Okay, I figured it out... I had just been thinking backwards about this.


This is what I was trying to achieve (reference attached screenshot). Notice how I was attempting to blend the colors across the terrain very smoothly? That's why it would have been such a large image... all those inbetween colors.

Thanks for helping me out, I think I have a much better understanding of memblocks now.


The one and only,
~PlystirE~

Urlforce:
Dude, I'd rather be declared a dbpro noob than an fpsc legend any day!

Attachments

Login to view attachments
Rain Man
16
Years of Service
User Offline
Joined: 19th Nov 2007
Location:
Posted: 24th Nov 2007 21:35
Quote: "Okay, I figured it out..."


What did you do?

Ten minutes to Wapner.
Pharoseer
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: Right behind you
Posted: 19th Dec 2007 10:28 Edited at: 19th Dec 2007 22:55
Plystire,

I just found this thread and I have to say, that looks awesome! I'd be interested in seeing how you did that. I've been working on that same idea of dynamic texture modification for a while now and haven't gotten very far with it. I've been writing an image blending library, but so far I've only finished the image arithmetic functions. I haven't started on the "masked" blends yet.

Are you using a bank of grayscale images to determine the transition between the images? I was thinking that would be a good way to do it. Then everything above 50% gray could be image1 and everything below could be image2 (for example). Then you would only need your stock textures (grass, dirt, snow, whatever) and your transition masks.

Anyway, I have a million questions, but I'll save them until I hear back from you.

[edit]

Never mind on the masked merging of images -- I just found my bug now it works fine. You said you did it on the fly though. How do you go about determining which mask to use? I posted a screen cap of what I'm doing now. Code is in C++, but maybe I can make something in DBP as well to post up.

[/edit]

Attachments

Login to view attachments
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 19th Dec 2007 12:43
Pharoseer, if you change "JPG" to lower case, we can view it

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 19th Dec 2007 14:48
I think your gonna run into problems Plystire, using 800 images is not a good idea. One thing I'm not sure if you've considered is using vertice lighting to change the colour of the image, rather than having lots of different colours, just colour the vertices and re-use the texture. The best bet is to have all your textures on 1 single texture, then UV map the memblock terrain to suit.

I've done this before in OIE, I used a matrix in the level editor, then in the actual game I make a terrain from it - with vertice colouring doing the job of lighting.


less is more, but if less is more how you keeping score?
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 15:44
Hmmm.... But how do you get multiple layers of Texture on One Object. Like DB seems to allow only applying ONE Image - (And dicing like you said VanB) - How do people "Recycle a texture" in random places over the object so when it exprts to Direct X - there is just one or two SMALL textures - just gras - and say Just a dirt one - but that use it like a paint brush randomly over the top of the object? TED editor does it - and to "Deal with DB" - It makes Two objects - a bottom and a "Alpha Layer" - Double Polys - but I still don't get how they seem to hav a texture "faded edges" centered on a vert... and Another Lined Up... Giving a "Spray can" Texture placement Effect.

That still baffles me.

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 19th Dec 2007 16:35 Edited at: 19th Dec 2007 16:37
I do that with Green Gandalf's shader, I have a hacked version that lets me load in 6 textures, then in an editor I paint the textures directly onto the terrain, here's a screenie:

http://www.thegamecreators.com/userdata/gallery/631_1024.jpg

I use pick screen and then paint by using 2 special images stored as memblocks, really I have it like a 56 bit image, I use black as a shadow. To make the grass less repeating I just use 2 grass textures and use noise to vary between them, works a treat. It's not ideal for the sort of texturing Plystire is looking for, but pretty good for more organic terrains.

Using a shader is a good option for performance in the long run - the methods that involve using lots of alpha transparent layers, well they are slow as hell, the shader is the only way I'll do it from now on.


less is more, but if less is more how you keeping score?
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Dec 2007 18:07
Ok - You're Screenie Looks Great - I agree the alpha "poly on poly is just stupid. If you wrote a 3d Engine - you just interpolate the textures on one poly - not do 4 passes thorugh Z-Buffer to render a Poly so it looks "neat-o" - I know its "efficiency" dumb - and Your Way - (I find shaders "heavy" too....) I bet is much lighter than rendering via POLY * NLayer - To Much ZBuffer Stuff - back fill interpolating - etc. Nasty.

Thank You.

Omen
17
Years of Service
User Offline
Joined: 7th Nov 2006
Location: Maple Grove, MN US
Posted: 21st Dec 2007 00:36
@VanB,

Much confusion from your last post...I've used GG's RGB mixer shader quite a bit (even made a version of it for DBO objects), but one thing about your last post puzzled me...

Once you make the changes to the 2 memblocks, how do you get those changes back to the images being used by the shader? You're not doing a MAKE IMAGE FROM MEMBLOCK every frame are you? That's the technique I tried and it was much much too slow (but maybe that's just my ancient hardware).

Also, I'm assuming you are using an AT for your terrain in your editor in that screenie since effects (in DBPro) can't be applied to meshes or matrixes... is that a correct assumption, or is there an undocumented command something like SET MATRIX EFFECT or SET MESH EFFECT ?

P.S. already tried them, they didn't work

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 21st Dec 2007 01:06
That's actually a weird LOD terrain mesh, like a matrix but it breaks down into larger tiles the further out it goes. I have it saved as a DBO, then I load it in and convert the FVF to 338, then I can apply the individual textures and the shader. The shader simply relies on these memblock images, it is textured with them at the appropriate UV coordinates for the real world position, then the shader does the rest. I just reposition and mould the terrain object everytime the camera moves, coupled with timer based movement it's pretty seamless and processor friendly.

I do actually update 2 image memblocks then convert them - but I have it working in such a way that it's pretty smooth, almost like painting in an art package. I do have a pretty decent GFX card and PC, so it's fast enough for my needs, it's actually quite fun to paint the terrain, far quicker with the editor I'm working on than other systems I've used. It renders a shading 'layer' when moulding the terrain as well, as the shader I use does not have lighting, I use the mask textures instead - it's actually twice the resolution of standard vertice lighting and will support shadows, so it's no bad thing IMO. If you've ever used the editor for Command and Conquer Generals, it's a lot like that.


less is more, but if less is more how you keeping score?
Omen
17
Years of Service
User Offline
Joined: 7th Nov 2006
Location: Maple Grove, MN US
Posted: 21st Dec 2007 01:33
@VanB,

<<nods heads>> Then, I'm assuming you are altering the terrain heights using the VERTEXDATA commands and using the SET PIXEL SHADER TEXTURE to manually assign the textures to the shader's texture slots?

jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Dec 2007 01:35
Awesome VanB! Tell me (if ya want) How'd ya do the "Weird" Lod?

I know there are a few "Poly Reducing" formulas one can use - but I thought a "Smart" Layout that had "Seamless" "Seams" <hehe> where the verts were welded ok - would work - like a cross between Roam and Lod. Pop Out the Highres version of Mesh with lower when you were in middle of a different "tile" or something.

How'd ya work yours?

P.S. I have slower hardware myself - and in some ways - it really keeps me on my toes with FPS. A Perfect dev shop I think needs a FAST box and a Slow Box.

Anyway - I think your system sounds neat.

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 21st Dec 2007 09:50 Edited at: 21st Dec 2007 09:53
Omen,
Nah, I just use the extra layer flag on TEXTURE OBJECT Obj,Image,Layer - before applying the shader. I use the vertex commands to alter the height and update the UV coordinate, which is really just a case of finding the appropriate height from a interpolated ground height function (very fast method) and using a multiplier on the X and Z coords to set the UV. I don't have to mess with normals because there's no hardware lighting on the terrain.

Jason,
I started with a big matrix with tiles at the top resolution, then I added double sized tiles around the edges, then did that again, so there's 3 levels of detail. It is quite tricky to get the transitions between detail levels neat, but no worries because I'd be happy to upload my LOD's. I have 2, one of them is quite big and good for like a FPS game, the other has only 2 detail levels and is intended for an RTS. My editor is still very early in development, so I don't mind uploading it as is.
I'll make a test terrain and upload a demo so people can see how it all works, might even add in some trees.

One key benefit in the way I do this is that there's no need to create and delete terrain objects all the time - I always end up with bugs when I do that, so having the terrain as an object that is moulded all the time avoids that. Anyone else find that creating and deleting a lot of objects causes some sort of memory leak? - my terrains usually end up pure white before very long.


less is more, but if less is more how you keeping score?
Omen
17
Years of Service
User Offline
Joined: 7th Nov 2006
Location: Maple Grove, MN US
Posted: 21st Dec 2007 16:13
VanB,

I think I might have been running into something similar to what you are describing with adding and deleting a lot of objects. I was developing a "dynamic details" system for street trash and debris for a city area. I would just randomly create objects at the outer radius from the chracter as the character moved. As an object moved out of this radius, it would slowly alpha-fade to invisible and then just get deleted.

It worked great - for awhile. After about 30 minutes, though, the debris started popping-in with no textures :/ The solution that worked for me was to create one "debris" object at the origin and then create multiple limbs for the total number of debris I'd ever want to see on screen at one time.

It was a bit tricky with the positioning because you basically had to "accumulate" the limb offset as you went down the limb list and when I wanted to re-position a bit of debris I had to update the limb positions of all the debris "down-list" from its position, but it worked and was much much faster and I've had it running for several days (using scripted character movement) with no problems.

BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 21st Dec 2007 17:00
A quick question about terrain limbs, as it seems to be on topic here. If you make a terrain using 4 limbs, would you create each limb starting at 0,0,0, move them and then attach, or would you offset the limb as you create it, so that each one is already "in place" if you position them all at 0,0,0?
Omen
17
Years of Service
User Offline
Joined: 7th Nov 2006
Location: Maple Grove, MN US
Posted: 21st Dec 2007 17:01
(sorry for the double-post)

<<smacks head>> Van B,

YOu know, I think I'm working on a system practically identical to the system you're working on. I've got these parts finished in my editor:

1. Area loading/saving
2. WYSIWYG object editor that includes:
-correct global/local rotation modes (using EZRotate)
-dynamic translation (just grab and move and it stays on terrain)
-automatic object stacking in dynamic translation mode
-object scaling
-global/local translation, scaling, rotation using "handlebars"
-manual property editing for all the above (via a GUI toolbar)
-Collision type, transparency mode, other property editing (via a GUI toolbar)
3. Area environment editing (via the GUI toolbar)
4. Entity positioning, scaling, rotation (enemy spawn points, sound emitters, particle emitters, lights)
5. Auto skybox conversion to a cubemap (using Evolved's cubemap shader) to make perfectly seamless skyboxes
...lots more

...I was just going to start on the terrain system using a method almost identical to the one you describe (even planning on using a hacked version of GG's RGB mixer shader) except my texture stage layout goes like this:

0: normalizer cubemap
1: Detail map
2: R8G8B8 mixer map
3: texture 1 color map
4: texture 2 color map
5: texture 2 normal map
6: texture 3 color map
7: texture 3 normal map

You can see some early screenshots here:

http://www.lakehomegames.com/omen_edit1.jpg

http://www.lakehomegames.com/omen_edit2.jpg

http://www.lakehomegames.com/omen_edit3.jpg


...would you ever consider "joining forces" on building an editor?

Omen
17
Years of Service
User Offline
Joined: 7th Nov 2006
Location: Maple Grove, MN US
Posted: 21st Dec 2007 17:14 Edited at: 21st Dec 2007 17:17
@BatVink,

I "accumulate" the curent limb offset in a UDT for each object and as I continue to add limbs, I increment this accumulated limb offset. Although I've never used this for terrain pieces, it should work the same.

In 3DWS, you just have to make sure you give a classname to each brush, and make sure that all the brushes that you want to be considered as 1 "object" in DBPro have the same classname. So, for example, if I have an arch made up of 36 brushes, I need to name them all "sewer_entrance_arch" or something like that so the code sees that I want to see them all as 1 object.

Hmmm, 1 block of code is worth 1000 words, maybe this will explain better (take a look at the propsLoad() function):

(uses Sparky's and several of Iam's Matrix Utils - won't run as-is since the dependent pieces aren't here, but should give you an idea)


jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Dec 2007 18:01
@BatVink. I did my limbed mesh with the Limbs Vertices Initially in thier correct position. So - They all have 0,0,0 "Position" and 0,0,0 Rotation. The Verts are actually where you see them.

This allows me to make my Dynamic XxZ "TILEs(limbs)" and Dynamic XxZ "Mesh Tiles".

Mesh Tiles
I basically have it so it allows a GIVEN "Square" to be whatever size you want Across and Down. Each of these "Units" is a two poly making a square. You also tell it how big they are in DBPro units.

Tiles(limbs) are the same way - in you can have as many as you want across and down... and these become the limbs... Though the Very First Tile I make as the Root Object.

It's my first Terrain-from-Scratch - So - I'm still learning but I'm quite pleased with the MESH aspects, Normalization of Vertex, and moving lights around and watching the "interaction" with the lights and polys... Next ... Stuff like these guys are doing - some sort of texturing solution - Maybe Static Shadows instead...of the Hardware lighting.... dunno.

Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 22nd Dec 2007 08:14 Edited at: 22nd Dec 2007 08:37
honestly, you really don't need a memblock to make a terrain. Its just that a memblock can store a large amount of data and transfer it into vertexdata fast. You could actually just read in the height values directly from a file into a locked vertexdata buffer if you wanted to. Its just faster to make a memblock from file() and faster to read from the memblock than read from a file. Memblocks are just temporary storage areas in memory.

edit:
I might get some flame on this, so I will explain. The only reason you need the memblock is because you have no way to specify the SIZE of the vertexdata, unless you have a mesh. So, you make the memblock first, formatted to the FVF you want, and then make a MESH from that memblock. Then, you lock the vertexdata, and deform the mesh. Another way would be to have a model mesh already made up. Load the model, then make a mesh from the model, and deform the mesh. The memblock method is just media-less.

edit again:
I wouldn't, and in fact don't use limbs for terrain tiles, for the fact that limbed objects draw all polys regardless if they are on screen. For smaller objects, limbs are ok, if the object is not onscreen. But terrain is always on screen. I tested this extensively. Try it yourself if you don't believe me. My method is individual tiles. Each tile is its own object. And since they are square, evenly spaced, not to hard to position them. Only problem I have, at the moment, is seams from connecting tiles. But, that is a normals problem, and I'm sure I can solve it.
Omen
17
Years of Service
User Offline
Joined: 7th Nov 2006
Location: Maple Grove, MN US
Posted: 22nd Dec 2007 15:16 Edited at: 22nd Dec 2007 15:16
@Visigoth,

And you're doing an awesome job - that USGS data manipulation is really looking good!

I haven't tested it myself, but it would make sense that "limbed objects draw all polys regardless if they are on screen" is correct -- if you are depending on the built-in frustum culling (which I believe in 6.6 is still object-based). Anyone correct me if I'm wrong on that.

However, (and this isn't a flame, just pointing out a salient point) when you manually hide limbs (by using HIDE LIMB), it does remove the limb's poly count from the result of STATISTICS(1) with a proportionate increase in framerate. So, you should be able to use that technique as effectively for a limbed terrain or a large city where each building floor is made up of separate limbs (which is what I was doing at the time I wrote that code to replicate the technique used for windows in City of Heroes).

Also, (just another salient point) wouldn't using a MEMBLOCK allow you to use the CHANGE MESH FROM MEMBLOCK command, which would be much much faster than doing anything with the VERTEXDATA commands? I say this because to use the VERTEXDATA commands you must first LOCK the vertexdata (essentially making a complete copy of the data) and then UNLOCK when done (copy back) whereas CHANGE MESH FROM MEMBLOCK changes the vertexdata in-place?

...just a couple thoughts.

BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 22nd Dec 2007 15:24
Visigoth, your method of a pre-made mesh is probably good for predetermined scenarios, where you know the size and resolution you need. I think the majority of people in this thread are focusing on making terrains that are flexible, hence the concentration on memblock meshes. I, for example, amd making a tool where I can specify the terrain dimensions, poly resolution and heightmap separately, and then create the mesh based on user preferences.

So far I've avoided using vertex commands to manipulate the terrain. In my head, I'm struggling to work out how I would efficiently work through the vertices and associate them back to a position on the heightmap. Is that something you have tried and have any advice on?

I've gone with limbs because I plan to manually exclude them rather than rely on them being automatically culled. Other discussions suggest making tiled objects can be much slower because of the overhead of the system checking objects. I haven't explored this any further yet.
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 22nd Dec 2007 17:34
@BatVink - Scope out http://forum.thegamecreators.com/?m=forum_view&t=120102&b=22 As I have a Code I zipped and uploaded (DarkGDK) but reads easy... It's not a HOW to do things efficiently - as its an experiment - learning app - BUT - I have code that calcs Verts... and more importantly in some ways than the code is a black and white image I put up there in in one of the posts - that explains the "Structure" starting from poly layout for one square (Where each vert is) and then how I build "MeshTiles" from that then finally how I make limbed "Tiles" from the "MeshTiles" ... and the part that is interesting is the code to move a vert and the code to look for adjacent ones.

I get into some stuff with vertex normals etc with a lot of help from other forum users.

Note - I'm taking this idea of keeping stuff in a memblock and working it like that - THOUGH - I will also make efforts to not have to DELETE CREATE objects and stuff - I'll go for slower if it means I don't need to keep creating and destroying objects. VanB and others have found this chokes after awhile in gameplay... (Objects - no textures etc.)

Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 22nd Dec 2007 20:11
@Omen-
I think the reason I don't use chnage mesh was because after I changed the mesh, the grid went back to being unwelded. Basically, change mesh reformatted the mesh to a non-welded grid, and that meant more vertices.

@Batvink-
I don't actually use a premade mesh. I was just throwing that idea out there. I looked back at my code and realized it was doable, is all. As for different size terrains, I can do that. The function takes in params for width, height, and columns and rows. It can be a 1x1 grid, or a 25x62, or anything, up to 100x100(because of the set object normals() bug). As for associating the verts to a position in a map, it is how I position the trees. Can also use it to reposition the vertices, say to carve a road or flatten a section of terrain to place a building. It works good. The trick was, when you load a non power of 2 image, to set the load flag to 1, I think, to retain actual pizels.
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 22nd Dec 2007 20:58
Omen, looking good - to be honest I think I'd just slow you down, this is like a side project for me so I don't have a lot of time to spend on it for now. If you want to pick my brain on how I'm doing things though then just give me a shout.

Batvink,
This code is how I mould my terrain to a heightmap:



Along with this height function, this is a really fast method of getting the ground height, much faster and more convenient than use line collision:


One thing you should be aware of when using multiple mesh limbs or objects is that there's no avoiding seams, like when each part of the terrain meet theres always a noticeable seam. By using 1 big mesh and updating it I can avoid a lot of issues like this.

I've attached a LOD.x file in case anyone fancies experimenting, uses a tilesize of 100x100.


less is more, but if less is more how you keeping score?

Attachments

Login to view attachments
jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 22nd Dec 2007 22:02
Quote: "One thing you should be aware of when using multiple mesh limbs or objects is that there's no avoiding seams, like when each part of the terrain meet theres always a noticeable seam. By using 1 big mesh and updating it I can avoid a lot of issues like this.
"


Now - BEcause its YOU - I'll 99% take this as fact! However, SO FAR - I don't have noticable seams in my Tiled Limbs. All the Adjacent VERTEX coords are set identical, I have a root of 0,0,0, and my Limbs aren't moved to their position - they are created with Vertex Coord values as if they were at position 0,0,0. (If that makes sense.)

So I'm saying maybe its the technique I used... and maybe its just because I haven't gotten fancy with textures yet - and maybe I'm just lucky - but I haven't seen this "issue" since I made my own meshs from memblock, created limbs, and implemented VERTEX NORMAL NORMALIZATION (for lighting)

Now - making the adjacents all be handled correctly was a trick... but... I wanted to make a note of my experience - and I make no claims to to say your wrong VANB - just I haven't had that issue yet using the methods described - ...YET... not to say I wont.

Omen
17
Years of Service
User Offline
Joined: 7th Nov 2006
Location: Maple Grove, MN US
Posted: 22nd Dec 2007 22:26 Edited at: 22nd Dec 2007 22:27
OK,

Here's my first attempt at realtime terrain texturing using a memblock terrain. The "alpha map" on this (actually it's the RGB mixer texture in the shader) is very small, only 128 x 128, so it looks really "blocky," but that's easy enough to change.

Also, no special brush features like gradients or mixing (yet), just real simple to show what it looks like. Also, the fps on my old Intel P4 2.6 Ghz/ATI Radeon 9600 workstation stays right around 300 (including the cubemapped sky shader)... so, not too bad

http://www.youtube.com/watch?v=oc1MqAqBoto

jason p sage
16
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 23rd Dec 2007 01:52
Looking neat already Omen.

I think you'll find that even once you add in blending and bigger brushes it'll stay at a decent frame rate, I like using my cheap'n'nasty tablet, with right click dragging it has a nice feel to it. When you can mix up textures it's possible to get some really cool effects, like spattering dirt over pathways, stuff that I don't think people do with other texturing methods. I like to have an indication of how big the brush is, I just made a small matrix mesh and overlayed it in the same way as the terrain mould.

The seam I'm talking about is caused by the edges of the terrain object getting blended wrongly, perhaps you've found a way around that - I tried offsetting the UV coords so that the edges are not at the actual terrain edges, but I was left with a sharp line instead. It's particularly noticable with mipmapping.


less is more, but if less is more how you keeping score?

Login to post a reply

Server time is: 2024-05-17 03:18:52
Your offset time is: 2024-05-17 03:18:52