Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Jul 2007
Offline Last Active Aug 19 2016 03:30 PM

Posts I've Made

In Topic: Binding consecutive attributes in buffer to non-consecutive indices

09 March 2015 - 09:47 AM

In case anyone was interested, I figured out the issue. As it seems to always go this was a user-error and the functionality works as expected when used correctly. I was trying to explicitly bind my attributes AFTER my GLSL program was linked, rather than before. My explicit choices were being discarded and the linker was using the automatic values instead.

In Topic: How much thought to put into terrain gen for specific use case.

02 November 2012 - 12:25 AM

I'm assuming your 1024^2 verts make up a grid of 1023*1023 quads, which is about 2 million triangles. That's a lot, but not an infeasible amount for modern GPUs.
Profile it and see how fast this brute-force method takes Posted Image

What kind of hardware are you targeting as your minimum spec?

Nothing archaic, but I'd rather not waste my polygon throughput on low-end devices on a stupid terrain mesh if I don't have to.

1024^2 is sort of my upper limit. Like I said, I'm going for a simcity-type system. I'd like to be able to raise and lower sections of the terrain and place units/buildings/whatever where the smallest thing you can place takes up one cell of the underlying terrain grid. I've never worked on anything like this before so I'm not sure if I'll need a 1024x1024 grid to represent a decent amount of space to play around with or if I'll need something more like 512 or even 256 cells to a side. Ultimately I feel like I shouldn't have to limit myself too much here, so I'm looking for ideas and suggestions on how to manage terrain for this type of system. There's the obvious sample-from-heightmap approach that brute-forces it, which seems very slow but would otherwise make editing the terrain in real-time a breeze. There's also a quadtree-based approach that I've already semi-implemented for terrain mesh simplification, but the actual simplification process introduces tears in the terrain that require complex stitching that I haven't tackled yet. Also, the quadtree approach seems like it wouldn't be the best way to handle terrain I want to allow editing of. I've seen some resources online about paging the data in chunks that sounds promising, but I wasn't really planning on having a vast landscape such that you couldn't see all of it at one time if you wanted.

I guess what I'd really like to know is how (modern) RTS engines handle this type of thing. I feel like most of the games I've played recently handle maps that are much higher resolution than 1024x1024 when it comes to editing terrain or placing objects.

In Topic: Efficient drawing of 2d gridlines with shaders

28 June 2012 - 10:23 AM

I don't get what you mean. If you bind a frame buffer with a texture, and then write to your quad as a fullscreen quad, you'd have the contents of the shader of the quad rendered to said texture. Is this what you're asking for?

In Topic: Vertex Attributes, VAOs and Shaders

15 June 2012 - 12:04 AM

So, essentially, in my case, I am able to get around the potential problems by rules of convention.

Heh, I was just coming back here to update and say that I spent the last hour or so implementing a static system just to see how it worked out, and I think I like it.

Like I said before, it was clever to be able to do it dynamically with hash maps of attribute names and locations but not being able to use VAOs was a huge strike against it. The new code is also simpler. I'm glad to see someone else taking this approach as well as it gives me confidence that this is viable (not that I saw many other options like I said).

I'm still interested in any other opinions / techniques people have got though!

In Topic: Acceleration structures for photon mapping on a GPU

12 April 2012 - 08:27 PM

I'm not really familiar with OpenCL, but in my implementation I just sorted all the photons along one axis (say the x axis). Then the middle photon (call it n) becomes the root of the tree. You can then recurse, sorting 0..n-1 and n+1 .. N-1 along the next axis (in this case y). That way the whole KD Tree building algorithm reduces to sorting, which presumably has some fast OpenCL implementations.

Yeah, unfortunately sorting is pretty complex to implement on OpenCL (not impossible though) and recursion is impossible. You can simulate it with a stack, but that's the kind of stuff I was hoping to avoid. I'm actually looking toward http://www.peterw.eu/photon-flipping.pdf instead. On page 43 he details a spatial hashing solution that exchanges high memory usage for not having to sort at all. It's actually really clever and seems to cater to the kind of work I'm doing at the moment nicely. I might still go with a kD-tree solution however, I just haven't made up my mind yet ;)