Changing terrain texture (ie. changing texture for part of a 3d object)

Previous topic - Next topic

kanonet

Future i would forget X_Collisionray, just write your own so it doesnt matter if all tiles are in one mesh or if every tile is in its own mesh. Its not to difficult (as long as x and z coordinates are constant, only y is different - but you screnshot looks like this is the case), X_SCREEN2WORLD is a great help here.

How do you draw this currently and how do you texture it? Cuz i would expect it to be to slow if you make each tile an individual mesh and even more slow to texture it separately (x_settexture is slow).

Fastest GLB sollution (but still slow?) should be to draw all with one mesh and to texture it with only one big texture. So if you want to change your texture  for one tile, just change its part of the big texture (use an array and MEM2SPRITE) and texture the mesh with the modified texture. Downside of this method is, that you can only have low res textures for individual tiles (but tile are very small on your screenshot, so it would be ok?) and that you will get problems if you make a bigger terrain. Of cause you can split your mesh and texture in parts (especially if you make a bigger terrain). I dont know about the speed of MEM2SPRITE, but it should be ok, especially for big sprites, but it should be ok, cuz you only need to call it, when you change the texture, not every frame, splitting mesh and texture in smaller parts can help here too, but dont make to many of them (see speed of X_SETTEXTURE^^).

A 2nd way to do it would be to forget native GLB commands and use Opengl calls. I would recommand to have a look at glDrawArrays and it dependants, check my X_SPRITE replacement to see how to use them. Advantage would be, that you could draw the hole terrain in one mesh and you would be able to change texture coordinates for individual vertexes. So just have all types of landscape in one texture and ad start all tiles texture coordinates pointing at the grass part. Over time you could change this coordinates so it will point at mud etc. So you need just one (smaller) texture, no matter how many tiles you have and it will be way more faster than the native GLB way. Only downsides that i know so far is, that it would be a bit more difficult at the beginning and that your terrain would not be able to cast shadows, but you still can cast shadows at it if you want (and i dont know if collisions work, i guess no - but i already said, write your own one).

Just two ideas, hope this helps you. If you need help to implement one of them, just ask me.
Cheers.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

FutureCow

No, nothing like powermonger (though it could easily be used for something similar). It's still a proof-of-concept at this point, I'll post details if it looks like I'm going to be able to produce the game I'm trying to.

Slydog

It may have been mentioned or suggested but I think your best option is to split your 128x128 map into smaller objects, such as 8x8 sections (which would be 16 by 16 of those small objects to fill 128x128).

Very similar to how MineCraft does it, except they have height / stacked objects to deal with.

The other advantage is it will draw faster if you are zoomed into a certain section where the entire field isn't in view.  You may have to do this manually, or maybe GLBasic or OpenGL does the occlusion culling for you.

It should be fairly fast to update / recreate an 8x8 object between frames. (rather than the entire 128x128 object!)
My current project (WIP) :: TwistedMaze <<  [Updated: 2015-11-25]

FutureCow

I had mostly dismissed the "split mesh into smaller meshes" plan as I didn't think it would give any savings when most tiles will change at various times (eg. a heavy snowstorm changes every tile to deep snow). What's probably obvious to everyone else - and hadn't occurred to me for some reason - is that the smaller meshes could be rebuilt in different game loops to spread the impact.

I'm not sure if the X_COLLISIONRAY statements will now add a lot more overhead as I'll have to do multiple checks rather than one, but hopefully OpenGL will know not to draw meshes that are off the screen and save cycles there.

Kanonet - if you want to lend any expertise here I'd be happy to hear it - my camera routine is pretty much a 6 degrees of freedom one (ie. it features tilt, zoom and movement so at any given time I might be zoomed so I can only see a few tiles, or zoomed out to see the entire mesh). I currently just do an X_SetTexture then a single draw object command.
I'm playing around with a few different ways to create the texture at the moment. Until I figure out the best way to do it, I'm currently just creating a 128x128 bitmap, drawing coloured pixels based on height at the correct location, then texturing the mesh with the image - 1 pixel per tile. I do want to do proper textures though rather than just 1 colour per tile.

Splitting the mesh might also change how I end up handling pathfinding on the terrain, I'll have to think about whether there are optimisations (or losses!!!) to be made there as a result too.... Hmmm....