Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 28 Oct 2007
Offline Last Active Jul 22 2015 04:44 PM

Topics I've Started

Slow terrain road editing

07 July 2015 - 01:04 PM

My road system is coming along nicely but I need some guidance. Currently, the user clicks on the terrain to add control nodes. If the road type is looped, 4 nodes will create a loop and any further nodes will add road sections to that loop between the 1st control node and the previously placed one. For non-looped roads, the road forms after 4 control nodes between node 2 and 3 and then any successive clicks adds between 3-4, 4-5, etc. as you can guess, I'm using a spline curve. It all works very nicely, the road mesh is created to nicely cover the terrain (a few points above it), and once you've laid down your nodes, you can move them around and stetch and bend the road as you'd expect from a simple spline curve.

The 2 problems I've got come when the road gets bigger. Firstly, the road is one big mesh and I'm wondering whether it would be more prudent to split this up into chunks. If the road has fairly high section content, i.e. there are more sections between control nodes, the mesh starts getting very big the longer the road gets. I'm using 32 bit indices so there's no problem there but I'm using some fairly keen terrain LODding so I'm not sure whether all that effort would be wasted for roads you're not going to see - I'm likely to chop the road up into manageable sections - is this usually how it's done?

Secondly, and the most important, when you're editing a simple 4 point road that covers a small section of the terrain (say 32x32 terrain tiles), it's very smooth and fast. When you extend the road out towards 256x256 and beyond upto 8192, it gets impossibly slow to edit.

I feel like I've streamlined my code a fair amount but some of the roads I'm envisaging for my game will be relatively long. Here's the breakdown of what I do each frame:

When the user adds a node and the current number for the current road is 4 or more, or the user moves one of the control points around after laying down the points:

Recompute the entire spline curve

For each control point section (the road between two control points), compute the length using a rudimentary 4 lerp points (keeps it quick). This allows me to keep the road sections (the numerous points along the arc) nicely spaced (user configurable).

Create a basic mesh of the road sections (this is for a visual guide only and doesn't include any geometry from the terrain but serves as the "cookie cutter" for the terrain/road geometry). This is done using cross products for each point along the curve. Whilst doing this, I also store the points of this mesh in an array for quicker reference later (for cookie cutting the terrain tiles).

Using each road section, I compute which terrain tiles (triangles) lie under it and add them to a "splittable" vector. I then take this splittable vector and pass it to a method which splits them against the 4 planes of the road section. These triangles are added to the final triangles vector. I then repeat this step for each road section in the entire road curve. Once I have this final list, I run through it getting the exact terrain height and UV coordinates and add it to the final mesh.

It's quite a complex and lengthy procedure that I feel like I've trimmed down quite a bit but it's still too slow. Am I generally on the right track with my steps? (No pun intended).. I'm wondering if I've missed something really obvious. After profiling, a sizeable portion of the time is spent cutting up the triangles against the road section planes and obviously if there are a lot of them to cut, it just makes it even slower.

I can post snippets of code if easier...

Any thoughts?

Calculating UV coordinates of a point in a convex 4-sided polygon

26 June 2015 - 12:35 PM



Is there an accepted and accurate method for determining the UV coordinates of an arbitrary point inside a 4-sided polygon?  Obviously if it's axis aligned then it's easy, but the polygon could be any shape (but always convex).  I'm trying to calculate the UV coordinates for my road.  Each section of road gets split up into more triangles so it can align itself to the terrain.


What I've tried so far is a bit convoluted (and hard to explain) and it didn't really work.


Any thoughts on how to do this?



Alpha blending roads onto terrain

23 June 2015 - 02:58 AM

After lots of work on my road system, I finally have a nice terrain-following mesh representing roads/tracks, etc.

The road mesh sits a tiny amount above the terrain but I now need to work out how to blend the road's texture map into the terrain's. Because I'd like my tracks to have some form of natural blend at the edges, I assume I'll need to alpha blend the road after the terrain is drawn. Is this actually possible or will I need to use some form of stencil? Can I use an alpha blend with ADD for this?

Roads,widgets and ECS

17 May 2015 - 12:14 PM

I'm adding roads to my engine.  I have a form of entity component system in my engine, the only probable difference between mine and most others is that I prefer entity logic to reside in the entity itself, rather than entities being data only and 'system's working on them.  I may switch it over at some point, but for the minute this works fine for me and feels more logical.


My question is around widgets and screen helpers and how they/whether they should fit into the entity component system.  To create a road, I'm adding a number of control points slightly above the terrain and using a Catmull Rom spline to connect them (I have already developed this functionality).  When a new control point is added, road geometry will be created 'underneath' the spline which will fit just over the terrain (z-fighting is something I'll look at later).  The user can then choose to bring the terrain up to match the spline (you can move spline control points up and down as well as in the x/z directions), or just leave it as it is (just using x and z and using the terrain's height).


I'm partway through it but I've hit a design issue.  At the moment, when a new control point is added, I just create a new Entity with a renderable component and a mesh component and add it to the scene (the mesh component is a simple small box at the moment).  Because it's added to the scene like just any other renderable entity, I can select the box and move it around using my normal object selection/moving functionality.  In order to keep all the nodes under control, I need some kind of object to own these nodes, like a TerrainRoad entity or something similar.  This would also contain the Catmull Rom Spline for drawing the lines between the nodes, etc. and possibly the mesh of the road geometry itself.


It doesn't really feel like this should be handled within the entity component system and it feels like I'd have to change the system to fit this model.  I would need something like:


Terrain Road entity

   \- Catmull Rom Spline

   \- Control node entities

   \- Renderable component (for road geometry)

   \- Mesh component (for road geometry)


This would mean entities owning other entities which I'm sure I'll have to support at some point but that would be more for sword in hand type stuff.  Should I continue trying to fit this model into the entity component system or shall I just leave that for actual game objects (like the resulting actual road geometry) and handle it in specialised classes?  Thing is, I would like to be able to select and move the control points around and I don't want to have to write separate selecting/moving code for that although perhaps it's that which is leading me into this design issue.


Any thoughts?

How much video memory do I really have?

06 May 2015 - 06:02 AM

In my MacBook Pro (using Bootcamp) on a GeForce GT 750M, the NVidia system information says:


Total available graphics mem:  4096MB

Dedicated video memory:         2048MB GDDR5

System video memory:             2048MB


It's advertised as a 2Gb card but I appear to be running out of video memory at just over 1Gb.  I'm handling several 8192x8192 textures for terrain editing (I don't stream whilst using the editor):


2 x D3DFMT_R16F 8192x8192 for flip-flopping the vertex texture (for terrain heights)

1 x D3DFMT_L8 8192x8192 for material type

1 x X8R8G8B8 8192x8192 for terrain normal


That's 4 8192x8192 textures I'm creating - Pix says 6 with an extra D3DFMT_L8 created by Direct3D (not the application) and another X8R8G8B8 - not sure why these are being created, so I've calculated all that (including the ones created without my consent) at 939,524,096 bytes, or 939Mb.  The rest of my textures/indexbuffers/vertex buffers according to Pix come to around 70Mb.


That makes it feel to me like I only have 1Gb of space to play in.


Should I be able to use that full 2Gb or not?