• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Dark Helmet

Members
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

173 Neutral

About Dark Helmet

  • Rank
    Member
  1. Beyond the assimp manual, see these for descriptions and code: * <a href="http://ogldev.atspace.co.uk/www/tutorial38/tutorial38.html">Tutorial 38 - Skeletal Animation With Assimp</a> * <a href="http://ephenationopengl.blogspot.com/2012/06/doing-animations-in-opengl.html">Doing animations in OpenGL (Ephenation OpenGL)</a>
  2. &amp;amp;nbsp; Re the geekslab page, yeah I tried that years ago and it doesn't work. Try this (for an arbitrary perspective frustum, with glDepthRange of 0..1): vec3 PositionFromDepth_DarkHelmet(in float depth) { vec2 ndc; // Reconstructed NDC-space position vec3 eye; // Reconstructed EYE-space position eye.z = near * far / ((depth * (far - near)) - far); ndc.x = ((gl_FragCoord.x * widthInv) - 0.5) * 2.0; ndc.y = ((gl_FragCoord.y * heightInv) - 0.5) * 2.0; eye.x = ( (-ndc.x * eye.z) * (right-left)/(2*near) - eye.z * (right+left)/(2*near) ); eye.y = ( (-ndc.y * eye.z) * (top-bottom)/(2*near) - eye.z * (top+bottom)/(2*near) ); return eye; } Note: "depth" is your 0..1 window-space depth. Of course, if you assume a "symmetric" perspective frustum (but not necessarily one that is 90 deg FOV), the eye.x/.y lines simplify down to: eye.x = (-ndc.x * eye.z) * right/near; eye.y = (-ndc.y * eye.z) * top/near; Now of course for mere depth buffer visualization, all you really want from this is "eye.z", which is linear depth value. So nuke the rest. Just map this eye.z value from -n..-f to 0..1, use that as your fragment intensity, and you're done: intensity = (-eye.z - near) / (far-near);
  3. OpenGL

    When timing with just SwapBuffers though, be careful. The problem ends up being the driver typically queues up the request quickly on the CPU and returns immediately (i.e. CPU does not block), after which it lets you start queuing up render commands for future frames. At some random point in the middle of queuing one of those frames when the FIFO fills, "then" the CPU blocks, waiting on some VSYNC event in the middle of a frame. This causes really odd timing spikes leaving you puzzled as to what's going on. If you want reasonable full-frame timings, after SwapBuffers(), put a glFinish(), and then stop your timer.
  4. Right depends on your goals. For most of us, right isn't defined by core but most efficient use of the hardware (fastest performance). So yes, agreed. If DL works for you use it. If you want more control over how your GPU memory is utilized, use static VBOs but you'll take a performance hit if you use them alone and you have to be smart about how you encode your data within them. If you happen to be running on NVidia and want VBOs with display list performance, use NV bindless to launch your batches with those VBOs. If not, then substitute VAOs in place of bindless -- it doesn't perform as well but it's better than nothing. Also, the more data you pack in your VBOs (the larger your batches), the less likely you are to be CPU bound launching batches (which is for the most part what bindless and VAOs strive to reduce).
  5. Cross-platform, no. But on NVidia, bindless can easily exceed the performance you get from VAOs, and the reason is intuitive. No you don't. Having a bazillion little VAOs floating around with all the cache misses that go with them isn't necessarily the best approach. Best case, use bindless (does an end-run around the cache issues, but is NV-only) or a streaming VBO approach with reuse (which keeps the bind count down, and works cross-platform). If you have a number of separate, preloaded VBOs, you absolutely can't/refuse to make them large enough to keep you from being CPU bound for some reason, and you can't/won't use bindless, then fall back on (in the order of the performance I've observed on NVidia) 1) VBOs with VAOs, one per batch state combination, 2) client arrays, or 3) VBOs without VAOs or with one VAO for all. In case it's not obvious, I do what gives me the best performance. I'm not a core purist. Its really unfortunate AMD hasn't stepped up and supported bindless in their OpenGL drivers, at least for launching batches (vertex attribute and index list specification).
  6. Originally posted by L. Spiro: Definitely! I was just re-surveying the CG book scene to see if anything new had developed here with more "meat" than sources I already have. Alas, no such luck. Here are some topics you might consider in addition to those mentioned above. 1. Skeletal Animation Math and Data Model used to pose a joint skeleton (clearly presented, in detail!) -- there are very precious few sources that do this well, which is why I put it first 2. Basic Skinning: Survey/detail of the most useful skinning techniques (DQS, SBS, LBS, etc., including shader code with extensive treatment of the math and pros/cons (candy wrapper, joint collapse/bulging, performance)) 3. Advanced Skinning (optional): Cutting-edge skinning techniques such as joint-based deformers. 4. Action State Machines (aka Animation State Machines; ASMs) (artist/animator-driven blending and state transition management; pros/cons and survey of main ASM features such as in Granny3D, Morpheme, Havok Behavior discussing not just what each common feature (node/connection type) does but why and how they work. Also, provide tips and tricks for "rolling your own" ASM.) 5. Attachments - Detailing the math, and any special considerations 6. Animation synchronization - Interaction with other characters (e.g. multi-skeleton animations) and the world (open, throw, catch, push, handshake). Emitting game events to kick off other actions (e.g. attach/detach, sound). Also things like sync between blended animations (e.g. limb-sync for walk-to-run and how to set that up) but you'll likely cover that under animation blending. 7. Animation Transitions - Pre-modeled versus blended; engine abstraction; tips and examples. 8. Root motion extraction/application techniques. AI interaction. 9. Behaviors - The AI linkage. Driving characters around. Managing character interactions. Making behavior look realistic and not "computed". 10. IK Details (not just solving, but authoring/publishing constraints, tricks for making them look natural and not mechanical, blend IK vs. solver IK, examples) 11. Performance - Tips/tricks for taking this and optimizing it for maximum performance (SSE, threading, offloading to GPUs, sharing animation data, optimizing transitions, crowds) 12. Animation Compression/Storage 13. Collision Detection - With/between skeletally animated models. Techniques. 14. Engine Integration - Layered design. Strategies for exposing skeletal/ASM capability to renderer and AI; abstracting animation details from the engine. 15. 3rd party SDKs and Toolkits - Just a jumping-off points for folks that don't need to rewrite everything from scratch, including open source and commercial sources. Bonus: Table and/or discussion of features comparing capabilities. A good bit of this can be dug out of a conference and journal papers, but that takes a lot of time, and you're still left with determining what's useful vs. what is "academic". Much of this I've never seen a good, consolidated reference for. For instance, I've never seen a great reference on #4 (ASM tech), save for vendor docs, and am very interested in this. Re #1, by far the best source I've seen out there anywhere is Gregory's Game Engine Architecture; also touches on a few of the others such as #4 a bit but didn't have enough detail for my needs. Highly recommend reviewing this source first to give you ideas on how to add value to the Character Animation book scene. Character Animation With Direct3D" is OK but just too light on details if you really want to get down and understand how everything works well enough to implement your own skeletal system which was my goal. Have flipped through quite a few more books including Computer Animation, Third Edition: Algorithms and Techniques, but most are just high-level surveys that don't have enough detail to make them worthwhile to purchase.
  7. Too bad we're talking Windows here not Linux. There you just setup one GPU per screen, create an X connection on the appropriate screen, and create a GL context on that connection (on NVidia at least). Pretty simple.
  8. GL_BACK_LEFT is a component buffer of the default (system) framebuffer. It is not the name of a buffer object. glBindBufferglCopyBufferSubDataI can easily see why you made this mistake though. Components of a framebuffer are historically called buffers (e.g. color buffers, depth buffer, stencil buffer; thus glDrawBuffer/glReadBuffer/etc.). These are different than buffer objects (arbitrary blocks of driver memory you can create). With framebuffer objects, these component buffers are called "attachment points" to help disambiguate these concepts.
  9. Doesn't sound right. This should be the full inverse of the bind pose transform for the specified joint (rotation and translation). For the root joint this might just be a negative translation (i.e. 0 deg rotation), but for child joints in general, this is not the case. Sounds like you're close. If trouble persists, would just do your transform compositing using matrices, and then just do a matToDQ on the tail end. Then later you can flip to DQs.
  10. Check out: * GLSL : common mistakes#Sampling and Rendering to the Same Texture NV_texture_barrier might be useful to you on NVidia specifically, but I don't know of a cross-vendor way to support this. OpenCL IMO is a non-starter except for limited use cases, as IIRC flipping back and forth requires a full pipeline flush/sync (that is, in the absense of cl_khr_gl_event / ARB_cl_event). An OpenGL Compute Shader is much more interesting in terms of avoiding that overhead, but I'm not an expert on those yet.