Jump to content
  • Advertisement

JoeJ

Member
  • Content Count

    1656
  • Joined

  • Last visited

  • Days Won

    12

JoeJ last won the day on November 8

JoeJ had the most liked content!

Community Reputation

3141 Excellent

7 Followers

About JoeJ

Personal Information

  • Role
    Programmer
  • Interests
    Art
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Most people agree to this, and to avoid confusion and bugs, using signed types for indices seems mostly preferred. Personally i only got used to unsigned numbers because some GPU API has forced me. Similarly, std::size_t has to be unsigned, becasue one may use a huge array requiring the extra bit. Still, if i can i use signed types. And i conclude disabling the warning is the lesser evil than messing with conversions or adding casts everyhere. I've never had an issue because of muting the warning, but i had some for the other cases. Edit: Seems a matter of personal preference. But we can choose, Java people can not - i really hated it's lack of unsigned types.
  2. The unsigned version works for the signed case too, so memorizing just that makes it a bit easier becasue the code is simpler. To be honest, it took me a long time to memorize this single line, haqving no more needing to looking up older code where i knew i used this before. Seems our brains are not made for counting backwards, haha
  3. After i is decreased once, it has tha value of size, which is still one too much and it is a bug. This is correct: for (i=stuff.size(); i-->0;) This is wrong: for (i=stuff.size()+1; i-->0;) Otherwise i know where all my bugs come from...
  4. Yes exactly. I assume this extension is faster than the regular atomic operations i had in mind:(https://www.khronos.org/opengl/wiki/Shader_Storage_Buffer_Object)
  5. I did not further reply after seeing in the NV presentation they mention robustness issues, I lack pixel shader experience, and other people should know better than me... However, i have good eperience with compute shaders, and i do not see the technical reason for the mentioned issues. What i have in mind is to use a atomic lock. So you need a single (guess 32 bit) varible per pixel to take ownership, and as long as it is set all other threads aiming for the same pixel have to wait until you are done with the sort. The sorting itself (or whatever else) so would not need atomic access and K entries per pixel would work. But now i'm no longer so sure this works as expected from pixel shaders? Performance might still be suboptimal if ther is a lot of transparency. The most elegant solution seems a 2 pass method for me: 1. 1st pass: Increment a atomic counter per pixel but nothing else. (Should be fast - e.g. the game Dreams does this with 64 bit atomics to splat points with a lot of overdraw and is still fast on PS4) 2. In a compute shader calculate prefix sum over entire screen. This gives a huge but compact list of all fragments that appear, and the first address for each pixel. (IDK how long prefix sum over 2M values - maybe 1 ms?) 3. 2nd pass: Draw again, this time again using atomic variable per pixel to get the local offset. Write the fragments to address + local offset. 4. Sort the fragment lists with compute shader. Blend and generate final image. But that's just a proposal - no idea if this is not practical for some reason, and how this compares to other methods. (The NV presentation might cover this already, but not sure after a quick look.)
  6. 1. No, but not 100% sure. 2. You can make a lock using atomics, some approaches discussed here: http://on-demand.gputechconf.com/gtc/2014/presentations/S4385-order-independent-transparency-opengl.pdf
  7. This works no matter if signed or unsigned, and also it looks cool : for (unsigned int i=x; i-->0; ) Adding to the question, i use int for iterating std::vectors, because mostly i need the index so iterators feel cumbersome, and i do indexing math with int. To get rid of the warnings i use #pragma warning ( disable : 4267 ) // 'argument': conversion from 'size_t' to 'const int32_t', possible loss of data But this looks bad bad practice. If anyone knows something better let me know.
  8. I work on automated tool to generate regular surfel LOD hierarchies and seamless UVs to apply them to the mesh since... >2 years now, so don't use surfels!!!! haha (Especially not with terraforming.) This also means i'm actually focused with geometry processing, and i got rusty with GI. I'm also not up to date with ambient dice, which is interesting but just another new format to to represent the data (you surely know this: https://mynameismjp.wordpress.com/2016/10/09/sg-series-part-1-a-brief-and-incomplete-history-of-baked-lighting-representations/) But i can mention some lesser known alternatives to tracing on how to calculate GI. With the cascaded SH grid i tried two methods. The first was Bunnells interesting anti-radiosity trick to avoid expensive visibility determination all together, mentioned on the bottom here: https://developer.nvidia.com/gpugems/GPUGems2/gpugems2_chapter14.html He uses surfels, but it works with volume grid too. Beasically each voxels needs to gather a volume of neighbouring voxels from all cascades. Simple but bandwidth heavy. He tried to make games from the surfels method on last gen consoles. Here a result but it did not became a thing: You see it is fast and looks good, but the visibility trick causes color shifting bleeding through walls, making it unpractical for complex interiors. He proposed to fix this with labeling rooms, but that's just a hack. For outdoor games however, the approach seems suited very well and i don't know why it has never been used. The second approach i tried was diffusion. (Similar to Cryteks LPV, but not relying on screenspace) This solves the bandwidth issue, but speed of light becomes noticeable slow. Using a single SH volume also can not represent multiple bounces well - for this multiple volumes, or at least a second one to handle indirect bouncing would be necessary. This seems an example: The reason i gave up on those things personally was the inability to represent complex interiors with voxel mip maps and resulting leaking for indoor scenes. Sharp specular reflections are out of reach with any of this, ofc. IIRC, they offer two modes, the cheaper one uses the voxels only for visibility determination, so they could be represented by a single bit. Less memory -> higher res to solve leaking, eventually. I guess it works somehow like this: https://software.intel.com/en-us/articles/layered-reflective-shadow-maps-for-voxel-based-indirect-illumination Maybe it's fast enough EDIT: I'm optimistic, looking at this for example: http://teardowngame.com/ Seems he does not do anything special: http://blog.tuxedolabs.com/2018/10/17/from-screen-space-to-voxel-space.html
  9. Sounds exactly what i meant. On the bunny (or a navigation mesh) it is more difficult becasue you need laplacian calculated from triangle cotangent weights to diffuse the energy (or heat) equally in all directions. Using a regular grid this is trivial i guess (or has acceptable error). But the main reason for their differential equation solver is to calculate the diffusion over any given duration (or distance) in one step, which would be too slow for realtime games. Hard to say what's faster when. I use Dijkstra too on the meshes, but working on a offline tool i can't say much about performance. Only this: If you would switch to navmesh, it is important to have good triangles avoiding small angles and area. Otherwise the cotangent weights become tiny and so the maximum timestep for stable diffusion per frame becomes tiny too. It would be worth to lie about the shape / area of bad triangles to trade accuracy vs. performance. With small amount of enemies it may be more the options of the flow method that are interesting than performance, like strafing around the target in a circle by rotationg the flow vector as you suggest. Likely target velocity can be handled in a similar way by rotating with angle related to distance, but A* can do this too by predicting the target offset. So i can not really help, but i see similar potential advantages you have mentioned. Worth to try
  10. I proposed something like this recently, and did not know it's already used in games and has name Some thoughts: It can be efficient, especially if number of enemies is large. Personally i use the approach for geometry processing, so on the surface of a triangle mesh, simialr to this: https://www.cs.cmu.edu/~kmcrane/Projects/HeatMethod/ (I have only little experience with game AI) But for path finding via local maxima search you do not need exact distance, just direction. So only the first equation system of the two from the paper, which is basically a diffusion of energy from the target. So this approach is scalar energy, not a vector. To find a path just look for the highest value in the neighborhood. The fastest way to calculate this diffusion is backwards euler integration using something like gradient decent solver or better, so not realtime. But for realtime a simple forward integration step per frame would work. Cost would be constant and only depend on the world size, but it it would take some time until paths onverge to the shortest (could even look nice and give more natural movement maybe). (... very similar to averaging vectors with their neighbours - i guess that's what you have in mind already, but the scalar vs. vector idea might be new for you.) If the goal is enemies avoiding to run into each other, you could build a graph over the enemies, color the vertices, and using a fast apporximate algorithm for this you get maybe 5-6 colors at max. So you would need only 6 fields to support any number of enemies. The problem would be: Graph colors would change per enemy form one frame to the next, which breaks the field integration from above Not sure if this could be solved somhow acceptably, but maybe it's worth to mention...
  11. I guess you have to match the transition to to coarser cascade. Likley the coraser always overlaps the finer, so fine data is always there but coarse is easier to miss? It should work somehow, even with constant step size per cascade. (But the step size should be one edge of a voxel, not the diagonl which is longer and so could miss one voxel. But otherwise i lack experience with constant step size. DDA surely works exactly, but is more expensive i guess.) I think it would be hard to get robust solid results eventually, and it is additional cost, also the internal vaxels could be unlit depending on what you do. So i would not give up yet. Maybe you need to have more overlap in case the center of corse cascades is empty. Unfortunately most people do not implement cascades, so there is little help, but it should work... This is what i tried many years ago for realtime GI. I i gave it up in favor of surfels, but maybe i can say something about it... What are your requirements, dynamic / static? Diffuse GI / specular reflections?
  12. Did not read it all, but there are two reasons for leaks - the first is voxel resolution too large to model a proper approximation of the scene which can't be helped, and the second is missing walls becasue too large steps while tracing. Looks your issue is the second. To fix it, you can trace in a way you sample every plane in the voxel grid so nothing can be missed, using a DDA algorithm. Seems this paper talks about it, but did not read http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.3443&rep=rep1&type=pdf
  13. I did switch to SSD for the same reason, but in my case it did not help with compile times.
  14. So OS is like Facebook, get it
  15. Sounds interesting. But i guess you still have to use SetCursorPos, and a useless message is generated? This sounds like you have some logic bug, because if you calculate the delta from the center it should be zero and the camerea should not ratate back. Sounds your mistake is that you calculate camera orientation directly from the delta, but instead you want to calculate it's rotation (or angular velocity). So it sould be like: camera.angleY += mouseDelta.x * someScalingFactor
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!