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!


SuperVGA

Member Since 10 Sep 2008
Offline Last Active Feb 17 2015 11:37 AM

Posts I've Made

In Topic: Fastest map-like collection for <GUID, BaseClass*> lookup

27 February 2014 - 06:40 AM

The comparision method isn't the fastest one. For lookup heavy maps I would sugguest the use of a hashmap instead.

 

 

 


But I kinda like the idea of using some big, fancy guids.

Do you really need a global, unique id  here ? What's wrong with a 32bit or 64bit application unique id ? It would be a lot faster and would make it even more useful in combination with a hashmap. Looks a little bit like over-engineering to me smile.png

 

Thanks for your input. Yeah, I have been over-engineering. It's probably because I've become so accustomed to these 128bit guids at work that I feel like I should be using those too. But you're absolutely right - less will definitely suffice. I'll moderate this, and overhaul this communicator thing with hashmaps and shorter uids.

I only want them to be unique application-wide, after all. 


In Topic: Geometry Clipmap Question

01 December 2013 - 07:09 AM

I'm back! Thanks Funkymunky, that did in fact help. I ended up understanding it, but before I sat down to rewrite some things,
I discovered that I would eventually have to deal with a patented approach, a Geoclipmaps apparently is.

 

So I went back to sort of a compromise. I do classic LOD chunks now, but baked into a single mesh, where every verex has its fp LOD value set as one of its attributes.

The cool thing about this is that i can use euclidean distances rather than manhattan or chessboard distances, and that I get a seamless result, as I lerp the LOD values downward towards the next chunk (which requires it's sample LOD to match its mesh density or be coarser.)

 

I now have

Attached File  standardlod.png   244.54KB   6 downloads

 

... And I'm now at the point where I'm actually considering applying a modulo equal to the highest density -quads, rather than using modulo of a chunk size. (here, the chunk size is constant, only the density changes)

This causes obvious but smooth vertex scaling in the distance, which I actually like. Viewing with the wireframe on also makes it more obvious.

 

I think I've managed to do a fair settlement, but you're welcome to input on the approach, of course! :)


In Topic: Geometry Clipmap Question

24 November 2013 - 01:30 PM

Ah, the only thing I meant by slide was the movement relative to the eye, before the modulo bit resets the positions of the vertices. I see how that was a weird term to use.

 

I've read so much and re-coded so much of this that I think I need to take a break. All this talk about grids is weird, when they are not really complete.

I somehow fail to comprehend why I should use an odd number of cells in the "grids". Also, is it supposed to be the innermost grid that's 2^n -1, or the surrounding ones?

 

Anyways, thanks for trying to help out. I thought I got it, but it appears that I didn't really do it how it's supposed to be done. And now I'm sorta stubborn to learn the "right" way. :)


In Topic: Geometry Clipmap Question

23 November 2013 - 03:26 PM

So you're talking about doing the degenerate triangles that marry the LOD levels, right?  I'm not sure why you say that "these in-between rings scale a bit".  They shouldn't scale at all.  The way I did it was to create the rings as static vertex buffers that use the Y vertex component to represent the LOD level they were a part of.  So each triangle is comprised of two vertices from the inner LOD and one from the outer; the inner ones have a Y component of 0 and the outer ones have a Y component of 1.  This lets me pick which LOD texture to fetch the height from in the vertex shader.

Hi Funkymunky! Thanks for responding. Yes - those are the ones I'm talking about.

The way you do it, do these triangles that connect the two LOD levels maintain size, and therefore overlap either the inner LOD area, or the outer one, as the camera pans across the landscape?

 

Because with how I do it, letting the innermost slide to a max of 0.25 (as the innermost quads are 0.25 in width and height), and letting the next layers slide by 0.5, 1.0 etc in each direction, there is at most a gap or an overlap between two LOD levels of the inner quad size. And this means that the gaps are often narrower.

But I see your point. Just as how I've mapped it down, there's still something I need to figure out....

Huh. - Could it be that I'm fitting the inner part of the coarser LOD to the finer? This means having fewer vertices to move around than if I used the outermost
triangles of the finer LOD level...

 

I keep my LOD value for the vertices in the texcoords, but it seems we do just about the same thing with regards to picking the applicable level.


In Topic: How to profile SIMD

24 October 2013 - 05:11 AM

 

Pass vectors by value, not reference

 

 

Hi Rob,

 

Why do you recommend passing vectors by value rather than reference?

I've made it a habit to use const ref parameters wherever possible, and wherever ref makes sense
compared to the size of the type (I wouldn't pass a char by reference)


PARTNERS