• 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.

Rannion

Members
  • Content count

    35
  • Joined

  • Last visited

Community Reputation

250 Neutral

About Rannion

  • Rank
    Member

Personal Information

  • Location
    Switzerland
  1. www.shadertoy.com will have a lot about this. You can do a search on star...
  2. Mosketch™ combines advanced sketching techniques and a powerful inverse kinematics solver to easily and quickly create 3D character animation. If you struggle animating your 3D characters or monsters, this tool might well save you a lot of time.   No need for complex rig, just a nice bones hierarchy and you are ready to animate. This is the beauty of it. You can even sketch over your bones to "draw" the animation.   There is few tutorial videos to watch on the web site to quickly understand the core principles.   Check out the web site http://www.mosketch.com/ and download the beta for free.    Any comments, or requests on the forum http://support.mokastudio.com/support/discussions will be much appreciated.   Thank you all for your assistance.  
  3. No, it's not really acceptable to generate them on the fly I would prefer swiftCoder alternative using quad-strip with a normal map then. And I guess I need to do it with a geometry shader which I'm not yet confortable with. Plus I need to work the math to know where to place my corners just knowing the middle top point and middle bottom point in world space.   So thanks anyway for all your suggestions.
  4. Well, after some tests, I want to avoid C0lumbo method just to render the cylinders only once. I cannot use the stencil buffer as I don't have the interface to use it.   So I tried swiftCoder method which seems great at first but it won't do what I want. My depth test is enable and I'm writing to it. The cylinders are z sorted and rendered front first and I have the blending enable. So I can see the scene through them but I cannot see other cylinders through them which is what I want, fine.   But the problem remains where they intersect in fact. And this is normal as the z being written is indeed behind at some point no matter which cylinder is being drawn first. So I guess this leaves me to ask for the support of the stencil solution... Or maybe ask for the support of glDepthFunc and set it to GL_NEVER...
  5. Thank you all for your answers. As I don't have access yet to the stencil buffer with our proprietary api, I'll try swiftCoder method which seems great to me.
  6. Hello everybody,   As you can see in the picture, I'm rendering a serie of cylinder which are dynamically moving. It's to show a sort of 3d path. Anyway, I want them transparent like how they are right now but as you can see where they overlap of course there is an artifact I'd like to get rid of. I'm using the usual settings: source = source_alpha and destination = one_minus_source_alpha.   Is there any state settings or any way to have the same transparency everywhere for those overlapping cylinder ? So where they intersect the alpha is not taking any other cylinder into account.   Cheers !  
  7. Thank you very much Spiro, you are such a helpful person. Don't know how you can reply to all those threads while still have your own work. Anyway this is much appreciated and I think you deserved a real thank you here.   You just replied to all my interrogations right now so, I'm going to give it another go very soon.
  8. Hi, as I'm rewriting some old stuff, I had a look at this thread and it seams really good. I might go for GGX specular soon. But I have a stupid question I guess, I was wondering about that line:   float3 l_diffuse = in_diffuse * PI_INV * NdotL;   Is it standard now to multiply by (1/pi) for the lambert term ? And also if I go for this model, is it applicable for directional, point and spot lights ? Or just for a specific one ?   Also as this is going to be way darker, I assume it HAS to be used with GGX specular to compensate, am I right ?   Edit: Got more questions now... How would one go from the old normal material model to this new one ? Like for specular I was using a specular colour with rgb and "a" was the specular factor. Specular power was also known as material shininess. Now we are left with the roughness which I suppose is correlated with the old shininess. And F0 which I'm guessing is what I had in the specular colour but this is pure speculation. Is there a way to transform one to another ?   Cheers
  9. Thank you for your answer. I'll have to do some tests. I'm guessing the pow(4) in unreal is for the cubic attenuation right ? I just don't like the magic numbers.
  10. Woah, nobody's working with Fbx anymore ?!? Or I am completly out of subject here ? Just let me know if my post needs more precision or anything that would help.   On the same register, my tech artist is saying that EmissiveFactor from Fbx is modulating the diffuse, so what is lighted is even more bright but then what is the DiffuseFactor in that case ?   When an artist is putting Emissive factor what is his ojective ? Same question for DiffuseFactor then.   Cheers !
  11. Hello,   I'm currently adding light attenuation to my shaders. (forward rendering) The formula I'm using is the following: attenuation = 1 / (attConst + attLinear * dist + attExp * dist * dist);   Now the real problem is how to put Fbx values in relation to that formula.   So far I have plugged what fbx call DecayStart as my attExp variable. It seams DecayStart is in the range 0..100 so I'm multiplying it by 0.01   Now I think this is not really what maya or 3dsMax are doing...   Fbx has also: NearAttenuationStart NearAttenuationEnd FarAttenuationStart FarAttenuationEnd   So now I'm really not sure how to compute all those, I mean I could invent something of course but I'd prefer something that is commonly used. Is there a new attenuation formula I should use ?  Does anybody know Fbx enough to teach me how to plug all those variable together in a nice attenuation function.   Thx a lot.
  12. Ok, for those who were following this ticket, this is dead simple. I guess I needed a good night...   To find the point E, I was projecting in screen space j2-j1 * radius. This is of course projecting the real 3d position. What we need to do here is to find the projected radius length which is on the plane of the camera so: j1 + camUp * radius; Project that result and then just do (projJ1Pos - projRadius).len() = projRadiusLength;   Then from here of course you can find E = projJ1Pos + (projJ2Pos - projJ1Pos).normalize() * projRadiusLength.   As mention in previous post, this is in screen space so we divide x and y by screen width and height, put everything in the range -1..1 and we are done. In the shader no need for view nor pojection transform, just modelToWorld transform.  
  13. Ok, I'm sorry but this is driving me crazy. I thought I had the proper E point coordinates in screen space but this is not the case.   Basically I have those 2 joints and in world space they have the same radius. But with the perspective projection and depending on the angle I'm looking at it, their proportions are changing of course.   But it seems I'm not able to find the radius properly, in screen space coordinates that is.   So could someone explain me how I could compute the length of the projected radius ?   I tried using the camera to J1 distance over focal length, then multiply that by my radius but it doesn't match.   I also tried to get the unit vector from J1 to J2, multiply it by the radius, project it in screen space, but even that is not giving me the flat radius.   First picture shows how it should look but from any angle point of view. As you can see in my second picture, my bone is not starting from E but a bit before and that is using the projected radius method.   So what would be the simplest math method to compute the distance from J1 centre to E ? (and again, this cannot be done in world space)   Tanks a lot
  14. You helped me to clarify the problem. It's not done yet but I need to do more tests. So now I have the point E which is along j1 to j2 at the edge of j1 radius. E is express in screen-space, I transform it in the range -1..1 and in the shader I don't do neither the view nor the projection transform. So now my mesh is always positioned correctly as I want it to just doing : gl_Position = modelToWorld * vertexPos; in the vertex shader.     That is a good step for me. Now I just need to scale it and orient it using the same method I guess. Scale shouldn't be a problem. I'm more afraid of the orientation. I'll have to do some more tests. Thanks for the help, I'll let you know.
  15. Hi, thx for your comments, here is a picture of how it should look like, well sort of. I definitly want the joints and bones to have a different scale so I don't want to use ortho matrix. The joints and bones are meshes, they have a geometry, they are not quad sorry. I called them quad just because they don't have any thickness and I render them as billboard but they are not quad.   The problem is to render the bone mesh between the joints so the bone mesh never touch the joints but is like attach to its border. And with the 3d perspective this is impossible to acheive if you look at my previous picture with the red cross you'll see that with those kind of angle in 3d the bone mesh will come from behind the joint of course.   I hope this is clarifying a bit the problem, but in this picture, we don't quite see the problem as there is no bones really that is along the z axis more or less.   I know this is very confusing and it's hard to explain the problem because it happens only if you look at it from an angle.