trs79

Members
  • Content count

    60
  • Joined

  • Last visited

Community Reputation

126 Neutral

About trs79

  • Rank
    Member
  1. Oh, no worries! Too many api's and combinations of extensions to keep track of :)
  2. Thanks for the responses everyone.   @froop: Yeah, I think over-optimization is to blame here, I hate it when that happens.  A draw call for each album seems like the way to go   @Norman Barrows: Thanks for the tip about sprites, I had forgotten about those. So it sound sounds like you're also saying to use a draw call per album, but using point sprites instead of quads?   @marcClintDion: PBO's sound interesting, but unfortunately they don't seem to be supported in GLES 2 that I'm targeting. I wish they were though, sounds like that would be the best way to update the textures
  3. Hello,   I'm planning on creating a program whereby a list of album names is retrieved via http. Once the names are received, I plan to do the following: Create a static VBO, with one quad for each album name. Each quad shares part of a texture atlas, so I can use a single draw call There will be additional http requests for album art images Display a loading indicator until image arrives, then lock part of dynamic texture atlas and write image data There will be a scissor clipping rectangle that will hide the quads not yet shown User can scroll list up and down   Questions: I'm using GLES, is there a better way to handle the asynchronous incoming images then to use a dynamic texture with locking overhead? Instead of one VBO for a single draw call, I could issue a separate draw call for each quad, not sure if this would be much slower? I think it would be easier because I could simply draw each quad with either album art texture or progress texture until image comes in   Thanks for any help, please see image below     I
  4. [quote name='jameszhao00' timestamp='1333440496' post='4927815'] SH = (roughly/sometimes) Light probes = environment maps = cube maps - Storage - Maps a direction to a color (or any value) - Light probes can mean SH, which is an approximation and can store blurry stuff. It cannot store sharp (high frequency) details. - Light probes can also mean environment maps / cube maps. They can handle sharp details. PRT = Precomputed Global Illumination - Method - Need to read paper... - Can store its results in some format... (paper mentions SH) Irradiance map = filtered map of incoming radiance. - [url="http://codeflow.org/entries/2011/apr/18/advanced-webgl-part-3-irradiance-environment-map/#irradiance"]http://codeflow.org/...map/#irradiance[/url] - Time saver. - For diffuse stuff in image based lighting, you usually sum incoming light for a given direction, with each light 'beam' weighted by its angle. That's your irradiance. - The summation is expensive, so we precompute a direction -> irradiance map. - Usually looks like a blurred light probe. - Stored in environment map, SH, etc... Also I feel like that unless you're reading a paper, the terms 'SH', 'light probe', 'environment map', 'irradiance map' usually are used interchangeably. [/quote] Thanks for the information, I'm beginning to get a better grasp of the terminology. It sounds like I probably just need SH for now, and I'll use standard shadow mapping for my characters on top of that. [quote name='InvalidPointer' timestamp='1333484141' post='4927989'] Spherical harmonics refers solely to the math/concepts behind storage, PRT is just the idea of calculating how light bounces around ahead of time. Technically speaking, boring old Quake 2 lightmaps are just as much PRT as are the fancypants spherical harmonics stuff that's in vogue today. [/quote] Thank you, that clears up a lot for me. So, to summarize, it sounds like to get the basic ambient indirect lighting I just need to do the steps by MJP. Just to make sure I'm understanding things now, it seems like both Unity and UDK are doing this, i.e. see this link [url="http://udn.epicgames.com/Three/Lightmass.html#Character"]http://udn.epicgames....html#Character[/url] lighting there it looks like they are just doing an irradiance map as well? The DirectX SDK has an Irradiance volume sample from ATI that looks similar.
  5. [quote name='MJP' timestamp='1333430748' post='4927785'] They're not using PRT in Unity, nor is PRT particularly popular for light probes in general. If you're just starting out with light probes, then you can implement them like this: 1. Pick your probe locations throughout the scene. Easiest way is a 3D grid. 2. For each probe location render an cubemap by rendering in all 6 directions 3. Convert the cubemap to SH (you can use the D3DX utility functions for this if you'd like, but it's not too hard to do on your own) Then at runtime you just lookup and interpolate the probes, and look up the irradiance in the direction of the normal by performing an SH dot product (just make sure that you include the cosine kernel). This will give you indirect lighting, and you can add in direct lighting on top of this. [/quote] Thanks so much for the reply. As I suspected, I must be confusing PRT with SH in general. So are light probes with SH like in Unity known as an "irradiance map"? (sorry I'm trying to wrap my head around the terminology). If this is the case, then as far as I can tell the main difference between PRT and an irrandiance map is PRT computes self shadowing whereas an irradiance map does not? Thanks for any clarifications. Basically, I'm just try to set my game up such that I can have nice indirect lighting mixed with lightmaps and direct lighting. It seems like light probes are how the commercial engines do it (UDK, Source, Unity, etc.)
  6. Hey all, I'm trying to see if it's possible to use the PRT DirectX tools to setup light probes similar to this from Unity: http://blogs.unity3d.com/2011/03/09/light-probes/ I notice there is a spherical light, as well as functionality to convert cubemaps to spherical harmonics coefficients. Any tips on how to be able to place light probes and create spherical harmonics coefficients from them? Thanks
  7. Thanks for the info, I could use placement new to get contiguous memory for particles in the same uniform grid cell as the particle I'm testing, but getting the particles from the surrounding neighbor cells is where I'm stumped. I'm not even sure if this is possible, but I'm hoping
  8. Hello, I'm trying to use SSE to speed up neighbor finding for a particle fluid simulation. My main issue, however, is storing the neighbors of each particle in memory such that I can quickly load all candidate spacial neighbors into xmm registers to begin distance testing to see if the neighbors are within the cutoff radius. I've tried Z-order morton sorting, but that doesn't always ensure that the spacial neighbors of a particle are stored contiguously in memory. Anyone have any ideas? Thanks
  9. SSE insertion sort?

    Thanks for the responses, to answer: [quote name='iMalc' timestamp='1325742149' post='4899862'] What type is the data (e.g. unsigned int, float, struct...) and what are typical and expected near maximum values on the number of items? Is it in an array rather than a linked-list? How often will the data actually be sorted already, and how often will it be nearly sorted? It might help if you explain where the data comes from. If I can get enough info from you then I can point you at the optimal sorting algorithm. I doubt there's much to be gained by trying to do it using SSE though. [/quote] Basically I'm looking to sort SPH fluid particles. Most of the time, they will be at rest inside of a small round container, with only occasional disturbances. I plan on sorting them with Morton Z-order according to what 3D spatial grid cell they are in, so they'll be spatially sorted inside of memory. I'm currently storing them in an array, and the min and max values should be somewhere around 9 and 25 respectively. Since the fluid will almost always be stable at rest, I'd say it's sorted probably 90% of the time. [quote name='Antheus' timestamp='1325772374' post='4899939'] Derive [url="http://en.wikipedia.org/wiki/Sorting_network"]sorting network[/url] for insertion sort and implement it as SSE. Sorting networks get around the lack of branching, but tend to be less efficient. For general parallelization, something like [url="http://en.wikipedia.org/wiki/Bitonic_sorter"]bitonic sort[/url] might be a better fit. All of these work best on 2^n-sized sub-sections, other sizes may either require padding or differently sized subdivisions, if possible. For SSE specifically, such methods tend to be best suited for sorting register-sized data (4xint SSE register, for example). Rather than general sorting, they tend to be used for selection or filtering, such as selecting smallest component of a vector, or as preparation pass for next stage. Biggest gain is ability to keep data in SSE registers instead of moving them back and forth for regular processing. [quote]would give as good performance for mostly sorted data sets[/quote] Heap sort, merge sort or tim sort. Insertion sort has that painful n^2 common case. Quicksort found in various standard libraries may be implemented as introsort, which should avoid typical qsort problems. [/quote] Thanks for the info, the Sorting network sounds interesting. Since the fluids will be 90% sorted I'm trying to optimize for the mostly sorted case, would the sorting network slow things down for that?
  10. SSE insertion sort?

    Thanks, I was afraid of that. My data sets is almost always going to be mostly sorted so it seems like the insertion sort would be ideal, even vs another algorithm that is SIMD capable. I'm not sure of any other algorithms that would give as good performance for mostly sorted data sets as the insertion sort.
  11. Hey all, I've looked all over the Internet but can't seem to find any examples of an SSE insertion sort. Maybe it doesn't lend itself well to SIMD? Anyone know of any good resources? Thanks
  12. [quote name='luca-deltodesco' timestamp='1323966858' post='4894202'] do you understand what the normal to a surface means? [/quote] I do, but this is my first attempt at coding collision detection, probably why I got confused on the implementation Thanks for the help, it was the z component that was causing problems, I finally ended up using this based on your code: [code] norm.Set ( -p->pos.x/diff, -p->pos.y/diff, 1.0-(p->pos.z/diff) );[/code] along with the initial boundary slope code: [code]float boundary = abs((-.4 * p->pos.z) + 9.8);[/code] Thanks again!
  13. [quote name='RulerOfNothing' timestamp='1323929951' post='4894094'] Here I am assuming the norm variable holds the normal vector of the container, which would indicate to me that it needs to have a non-zero z value if the container is a frustrum instead of a cylinder. [/quote] Thanks for the reply, you are correct the norm variable holds the normal vector of the container. Unfortunately when I change it to have a non-zero z value I still get the erratic particle movement, i.e : [code] norm.Set ( -p->pos.x, -p->pos.y, p->pos.z ); norm.Normalize(); [/code] Maybe I need something different for the z value?
  14. Hey all, I'm seeing some strange behavior from some SPH fluid code I'm working on. I modified it to have a cylinder as a container/collision shape and that works fine. However, I then change it so that it slopes inward as it gets taller, and the particles start to move around constantly like the fluid is boiling and they never settle down. Also, the fluid level doesn't get higher as the container slopes inward as I'd expect. See image: [attachment=6419:fluid.gif] Here is the code I'm using to calculate positions (it's a modified form of the code at [url="http://www.rchoetzlein.com/eng/graphics/fluids.htm"]http://www.rchoetzle...hics/fluids.htm[/url]) [code] accel = p->sph_force; accel *= m_Param[SPH_PMASS]; ..... // p is the particle structure, with z being up // radius is the particle radius // norm is a 3-vector float boundary = abs((-.4 * p->pos.z) + 9.8); diff = 2.0f * radius - (boundary - (float)fastSqrt_2(p->pos.x*p->pos.x + p->pos.y*p->pos.y)) * ss; if (((diff < 8 *radius) && (diff > EPSILON))) { norm.Set ( -p->pos.x, -p->pos.y, 0 ); norm.Normalize(); adj = stiff * diff - damp * norm.Dot ( p->vel_eval ); accel.x += adj * norm.x; accel.y += adj * norm.y; accel.z += adj * norm.z; } .... // Leapfrog Integration ---------------------------- vnext = accel; vnext *= m_DT; vnext += p->vel; // v(t+1/2) = v(t-1/2) + a(t) dt p->vel_eval = p->vel; p->vel_eval += vnext; p->vel_eval *= 0.5; // v(t+1) = [v(t-1/2) + v(t+1/2)] * 0.5 used to compute forces later p->vel = vnext; vnext *= m_DT/ss; p->pos += vnext; // p(t+1) = p(t) + v(t+1/2) dt [/code] I'm pretty sure the way the normal is being added to the acceleration is causing the "boiling" of the particles, but I'm not sure. Thanks for any help