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 Yesterday, 06:37 AM

Posts I've Made

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

27 June 2015 - 02:40 AM

I worked out a really simple solution for this which works well enough for what I need and is really quick.  I basically made a plane out of each side of each road section (each road section has 4 sides) and for opposite sides then took the distance between the point and the plane and made a percentage out of that for U and then did the other opposite sides for the V.  I already compute the planes for splicing up the sections to fit on the terrain, so it's actually pretty fast.  There are some very minor artefacts if you look closely from above where the textures are very slightly skewed but you'd have to really look hard to see it and the road will never be viewed from that angle anyway.  It's also only apparent with my test texture which is a grid, for tracks and roads you can't tell.


Onwards and upwards!

In Topic: Alpha blending roads onto terrain

23 June 2015 - 04:33 AM

The options you have depends a little bit on your rendering technique. I.e. in a deferred engine you could project the road onto the terrain.

That bit is kind of already done. I'm projecting the road, in a fashion, by creating the road mesh and then splicing it up using the terrain triangles/heights so it's its own mesh and entity. It looks identical to how roads are created in Crysis 3. When you move the road around and adjust the control points, the mesh rebuilds itself to match the new contours.

I guess I'll just try the alpha blend and see how it looks.

In Topic: Roads,widgets and ECS

17 May 2015 - 03:15 PM

I guess it may of depend on how "interactive" your road is with the rest of game? It's hard to say where the best place for it is without knowing more details about what roads are used for. Like if it's just a static mesh that gets rendered on top of the terrain and that's it, it might be simpler if it were just a separate thing (like terrain presumably is?). But if there are multiple roads, and they can be - I dunno - modified in game, or created/destroyed, then they might make more sense to be entities (are the spline and control nodes used during gameplay?). Ideally, I wouldn't force a game design based on limitations of the editor though.

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.

A parent-child relationship for transforms is obvious, but there's nothing stopping you from expressing other parent-child relationships in the ecs. Inventory->Items, Team->Players, Road->Control nodes. Don't think of it as an entity "owning" another, but simply there being a relationship between one entity and another. This relationship can be expressed in a component (e.g. a TransformChildren component containing a list of entity ids for its "children", or an Inventory component containing a list of entity ids for the inventory items). Just some food for thought.

Thanks, this helps a lot.

The road isn't interactive at all, it's just decoration really - a static mesh over the terrain, although I'll need to know when the player is on it but that'll be handled later.

I guess I was looking for it to just slot in but obviously that's not going to happen. The component to specify the relationships is a good idea.


In Topic: How much video memory do I really have?

07 May 2015 - 03:04 AM

shouldn't all modern GPUs support paging? at least nvidia Fermi+ (GTX 4x0 etc.) support the sparse texture extension of OpenGL, which allows you to stick together textures out of random memory pages, so there shouldn't be really a fragmentation >= 64kb of texture size. (unless the drivers restrict that for some reason).

Under Win32, the biggest fragmentation issue is address space - each process has ~31.5 bits to address all of it's resources.
Virtual paging does nothing to fix address space fragmentation - e.g. even if paging let's us assume that the physical RAM is infinite, we need to be able to claim a large contiguous block of virtual addresses/pages.
As for the D3D9 era, they might not use paging, and might even store addresses using <24bits in places (e.g. by assuming 256byte alignment, 23 bits can fully address 2GB).
As for mips, on disk they add an extra ~33%, but sometimes in video RAM they can add ~mip0pitch*(mip0height-1) -- aka (~100%).
Are you running fullscreen or windowed? Fullscreen might reduce the amout of VRAM that the OS is reserving for itself.

In this particular instance I'm in windowed mode. My editor is a c# app but it 'automates' my c++ engine where it passes windows handles for the engine to render to. I had included my various frame buffers in the 70Mb in one of my earlier posts.

As a further test, I added around 20 terrain layers to an area of the 8192x8192 terrain each with diffuse, normal and specular maps all being rendered from the same viewpoint and had no memory issues at all. It does just appear to be that call to save texture to disk.

In Topic: How much video memory do I really have?

06 May 2015 - 05:32 PM

It would depend on how you're saving to disk, really.  Are you using D3DXSaveSurfaceToFile or rolling your own?


Yes (albeit D3DXSaveTextureToFile)



The fragmentation comment was interesting - as these textures are (should be) always on the GPU, are they susceptible to fragmentation or is that only when textures are loaded/unloaded/loaded, etc?


I actually don't know, but I assumed. Maybe someone who knows more can answer. I don't know enough about the details of how 

a D3D9 texture is managed on the GPU - but if anyone external to the driver (or whatever) holds a pointer to that memory, then it can't be moved around in the GPU's (presumably 32-bit?) address space, so I assume you'd be subject to fragmentation.


When exactly do you get the out of memory error? What API call are you making? D3DXSaveTextureToFile? So maybe it's just related to that function. Maybe it writes to a memory buffer first and it can't allocate a big enough chunk? Is this a 32-bit process?


What does the DirectX debug runtime say? Anything interesting?



It's a Win 32 bit process. The runtime just says out of memory and the HRESULT for D3DXSaveTextureToFile also returns the code for out of memory.  It's quite odd, I've created a couple more 8192 x 8192 textures on top since the error and it's still working fine and they are being used.  I guess I just won't call that method and roll my own.


Thanks all