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


  • Content count

  • Joined

  • Last visited

Community Reputation

933 Good

About Lightness1024

  • Rank

Personal Information

  • Location
  1. Ok little report from the front. I figured that one big problem I have is a problem of precision during reconstruction of the 3d position from the lumel position. I have a bad spatial quantization, using some bias helped remove some artefacts, but the biggest bugs arn't gone.   anyway, some results applied to real world maps show that indirect lighting shows and makes some amount of difference:   (imgur album)      
  2. Awight, there we go, the drawing:   Ok so with this, it's much clearer I hope, the problem is by what figure should I be diving the energy gathered at one point ? The algo works this way: first pass is direct lighting and sky ambient irradiance. second pass creates photons out of the lumels from the first pass. the third pass scans the lightmap lumels and do the final gather. The gather works by sending 12 primary rays, finding k-neighbors from the hit position, tracing back to origin and summing Lambertians. Normally one would think we have to divide by number of samples, but the samples can vary according to photon density, and the density is not significant because I store a color in them. (i.e. their distribution is not the mean of storing the flux like in some implementations) Also, the radius depends on the primary ray length, which means more or less photons will be intercepted in the neighborhood depending if it hits close or far. And finally the secondary rays can encounter occluders, so it's not like it will gather N and we can divide by N. If we divide by the number of rays that arrive at the origin, we are going to have an unfair energy boost. I tend to think I should divide by the number of intercepted photons in the radius ?   Edit: that's the photon map visualizer. I made so that colors = clusters.
  3. Hey guys, I wanted to do some reporting on a tech I'm trying to achieve here.   I took my old (2002) engine out of its dusty shelves and tried to incorporate raytracing to render light on maps, I wrote a little article about it here: https://motsd1inge.wordpress.com/2015/07/13/light-rendering-on-maps/   First I built an adhoc parameterizer, a packer (with triangle pairing and re-orientation using hull detection), a conservative rasterizer, a 2nd set uv generator; And finally, it uses embree to cast rays as fast as possible. I have a nice ambient evaluation by now, like this:   but the second step is to get final gathering working. (as in Henrik Wan Jensen style) I am writing a report about the temporary results here: https://motsd1inge.wordpress.com/2016/03/29/light-rendering-2/   As you can see it's not in working order yet. I'd like to ask, if someone already implemented this kind of stuff here, did you use a kd-tree to store the photons ? I'm using space hashing for the moment. Also, I have a bunch of issues I'd like to discuss: One is about light attenuation with distance. In the classic 1/r*r formula, r depends on the units (world units) that you chose. I find that very strange. Second, is about the factor by which you divide to normalize your energy knowing some amount of gather rays.   My tech fixes the number of gather rays by command line, somehow (indirectly), but each gather ray is in fact only a starting point to create a whole stream of actual rays that will be spawned from the photons found in the vicinity of the primary hit. The result is that i get "cloud * sample" number of rays, but cloud-arity is very difficult to predict because it depends on the radius of the primary ray. I should draw a picture for this but I must sleep now, I'll do it tomorrow for sure. But for now, the question is that it is kind of fuzzy how many rays are going to get gathered, so I can't clearly divide by sampleCount, nor can I divide by "cloud-arity * sampleCount" because the arity depends on occlusion trimming. (always dividing exactly by number of rays would make for a stupid evaluator that just says everything is grey) ... I promise, a drawing, lol ;) In the meantime any thought is welcomed
  4. If your list contains multiple, non-polymorphic datatypes, then you are doing something evil (or spent too much time in LISP).   Edit: just to clarify, a list containing multiple, non-polymorphic datatypes is almost impossible to operate on idiomatically. You are forced to either know the exact type and order of each element ahead of time (in which case a tuple would be more appropriate), or fallback to a chain of [tt]if insinstance(a, Foo): else:[/tt] statements, which is just bad software design.   Certainly not. python can work on different types just like some kind of type erasure system. they are not polymorphic but some operations can apply to a whole variety of types. This is the same than working against the highest interface in OOP. In python you can do it too without any contracts. take a look at that : http://lucumr.pocoo.org/2011/7/9/python-and-pola/ There is not even a mention of classes and inheritance and yet python can accept code that is even more powerful than multiple inheritance, because you can work against "operators" (c.f `len` example in the link). If you keep that in mind as a discipline when writing functions, you open your possible accepted types to a larger variety.
  5. You don't want to write half a page because .... you are lazy ? It will be tough implementing a nice ocean system if you are that lazy. Choose, either you don't care about sharing what you do, or you care and you write your half page. Half a page is nothing, read at least the papers you linked, how many pages do they have ? how many months you think it took those researchers to do their work AND cherry on top, write about it and share it publicly ? Meanwhile, what are you doing ?
  6. yes report quickly because its going to get out soon, and ms implementation of C++11 seems to already have enough basic bugs like that on its record. I reported one myself. seems like they have a poor test suite, or/and just few users really using their soft.
  7. You're all wrong, you should use morton code (z order) for better cache coherency on adjacent cells :p
  8. There is a major limitation in Express editions compared to Pro/enterprise/ultimate, you cannot install plugins. So no visual assist, no incredibuild, no phat studio, no global zoom, no resharper or watnot...
  9. Are you sure this is even this extract of code that takes 1 hour ? when you pause the debugger it always stops in this function ?
  10. Then I surely need to read it again. In the meantime would you care to develop on this point ? Because it seems it would help OP in his situation.     Ah yes, I confused 2 concepts a bit fast. However, I don't see how a wait free queue would be a good thing. I really think an "executor" thread that takes jobs from a queue, and is designed to be possibly idle for long periods of time, SHOULD definitely wait, like in the sense of being totally set to sleep by OS de-scheduling. Otherwise what are we talking about ? a wait-free queue, that means that you can do some operation looking like "tryQuery" or "tryPop" or something and you're sure it will return without ever waiting. Am I right ? Then what do you do ? You go do other stuff or you loop on the tryPop ? The latter would be very bad in my book if by design this threat is supposed to possibly wait for extended periods. I think it is a real nice value to have a "pop_or_wait_until_something_comes" method on the queue, that will wake up the sleeping consumer with a condition variable. This allows to get a low power consumption for the app/game. Nowdays cooling sinks are really badly designed so using the CPU less means you are very likely to get more power when it matters. (because of if you keep sucking cpu work for polling, it gets hot, and then throttles down, and then when you really need power you get a slug instead).   Awight, those were my concerns. So now based on this, I would like to hear, constructively, how could the OP answer these criterions while still using a wait free queue.     well actually you already answer it somehow in the last part, if I understand correctly, basically you say that when the tryPop fails, then it is ok to lock and wait on the condition variable. sounds like double step locking. hm...
  11. you can only work lock free safely on structures that work with plain primitive integers. what are you going to do with that ? you need to push function objects, so unless you work out a complex permanent memory position pooling technique and your lock free structures manipulate indices in that pool only, you have no exit. read this document: http://erdani.com/publications/cuj-2004-10.pdf you'll realize that   also, without condition variable, lock free also means wait free, and thus you're going to need to embark in some crazy scheme where you need to recycle your job executor thread, into something that can make useful stuff during the moments there is no job; otherwise you need to spin and generate heat for nothing. Recycling a thread so that it can metamorphose into your rendering loop for example, would not be something I'd recommend to do. So why try going lock free when nothing said you would gain any perf than when using mutex+CV ? not mentionning much easier invariants proofs, better power usage in case of bubbles, software engineering sanity, etc...
  12. If the music can manipulate the visuals, I guess this can only happen through a mic ? In my opinion it remains possible in a high level IDE but you will have to add the specific coding that will do this original idea, because I see no good way of integrating this without programming. It is possible to program "personal" behaviors in Unreal or Unity, they are flexible enough to allow this.
  13. You guys are lucky to be able to propose that at all in the first place. One time I tried to use a formula for hashing (one line of code) taken from boost, and some mail came back saying I was using something from outside which is not acceptable. In what industry to you guys work ?