Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Feb 2011
Offline Last Active Jun 16 2016 03:49 PM

Posts I've Made

In Topic: Resources/approach for 3D tile/height map rendering

15 June 2016 - 05:52 AM

Well tried a few things to have chunks with a level of detail based on distance (merging 2x2, 4x4, etc. tiles into a single tile), but avoiding visible seams is proving an issue.

Solved it to an extent by adding vertical edge pieces going down to the lowest height, so at least no gaps to see through. Seems like a bit of a hack though.

In Topic: Resources/approach for 3D tile/height map rendering

03 June 2016 - 01:45 PM

Well yes, hadn't really though about the size maths since each vertex is small lol. Well guess the low-end and laptop GPU's wouldn't be able to render so much in detail anyway.


Since your vertex buffers really never need to change (i cant think of why individual vert positions or normal vecs would need to change on a textured height map) then I would definitely use an immutable buffer.

The heights can be changed slightly at runtime though. e.g. to flatten a bunch of tiles for a building or road. But I guess maybe for such things its OK to just create a brand new buffer and throw out the old one, more or less what I expected a write-only map/unmap to do behind the scenes.



But still, is such a triangle list really the normal approach all these games took/take? Found lots on the things various FPS/third-person games take for indoor areas or comparatively small outdoor areas (to only render the rooms the player can see, and simply lower detail meshes with distance for independent objects/entities), but not so much for large outdoor areas, even though games have been doing it for years while keeping pretty good detail for close terrain.


Is the "100x100 chunks but keeping the borders full detail" a suitable idea, or should I have a better look at algorithms to deal with borders, since I don't really need full detail "lines" joining distant regions? Obviously putting a low-res region directly next to a high-res one while doing nothing else is liable to leave gaps along the edges where the gradient changes.

In Topic: Resources/approach for 3D tile/height map rendering

02 June 2016 - 03:42 PM

Not right now, although its not an immutable buffer, maybe I need to play with the creation flags. At some point id want to update sections where the world gets changed, but all I did in my test was Map/Unmap the constants buffers to take an update camera matrix, cleared the render target, a few Set* calls and the single DrawIndexed. Not even got textures in play there yet.


CPU usage was around 0.5% in task manager (i7-4790K), although didn't run the profiler on it.


EDIT: Actually changing the usage flag was a lot faster, guess the driver put it somewhere the GPU cant access efficiently before, even though i never made it CPU readable. I also only just realized that such a vertex buffer is still 100's of megabytes, depending on how much data I need in a Vertex, so I guess that is not a particularly good thing either.

In Topic: Code vs. drag and drop in Game Maker

02 June 2016 - 11:33 AM

You can translate all the drag and drop parts directly to GML pretty easily. This means you can teach all the important concepts (objects/classes, events, variables, conditionals, inheritance, etc.) within the "simple" drag and drop environment.


GML is however able to go far beyond what those drag and drop actions can do practically.

You can also combine both, create reusable scripts, or even create custom drag and drop components which can make for a good middle ground, and a good introduction to GML.


Personally many years ago I found that a really useful feature, because I was able to basically learn GML that way. e.g. I had a space invaders like game in pure drag and drop.


But then I wanted more complex logic like intelligent turrets that could select the best target, and have some chance of hitting fast targets. Or particle effects for explosions, impacts, etc. rather than simple pre-made animated sprites. Or the ability to load, edit and save levels using text files, not just pre-made game maker rooms, so started to include GML scripts. In the end I had nearly the entire game in GML.


This wasn't out of some drive to learn GML specifically, but as a means to add the features I desired to my game, and not be limited because no drag and drop item existed to do what I wanted.

In Topic: Resources/approach for 3D tile/height map rendering

02 June 2016 - 08:10 AM

Seems to be the vertex shader limiting it. If i intentionally transform it out of view, so nothing for the pixel shader, the frame rate is the same.

The 1000x1000 test mesh I created is already in world space. The vertex shader just multiplies the vertex position with the camera matrix and copies the rest of the fields over (normal vector + colour for now). Also occurred to me that making a triangle strip is a lot harder than on first consideration since differnt tile types have different textures/uvs, and the edge tiles are multiple textures.

Smaller chunks with culling is something I intend to do, along with fog, for larger map areas , but was hoping with modern gpu's could have somthing near this in view at once.

Could maybe do a level of detail thing by having say 100x100 chunks but keeping the borders full detail? Not sure how hard that is to create along the edges. Seems fairly complex along with optimising flatish, single texture regions.

Will have to see what tessellation can do. Not something I have used.

Not sure how instancing is meant to work? Seems unlikely and hard to determine tiles with the same textures and geometry even if i restrict the height map to 8bits?

Still feeling this is getting overly complex though and missing a simple solution, or at least a well known one to implement that has already gone through the process of figuring out the ideal approach, and what optimidations are worthwhile. I can think of many older games that did this predating modern GPU's and features.



shader is just this right now.

//vertex shader
Output main(Input input)
    Output output;
    output.pos = mul(input.pos, viewProj);
    output.normal = input.normal;
    output.colour = input.colour;
    return output;
//pixel shader
float4 main(Input input) : SV_TARGET
    float lightIntensity = saturate(dot(input.normal, lightDirection));
    float4 colour = saturate(input.colour * diffuseColour * lightIntensity);

    return colour;// * texture2d.Sample(samplerState, input.uv);