Jump to content
  • Advertisement

leith

Member
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

120 Neutral

About leith

  • Rank
    Newbie

Personal Information

  • Role
    Producer
    Programmer
    Technical Director
  • Interests
    Art
    Audio
    Business
    Design
    DevOps
    Production
    Programming

Recent Profile Visitors

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

  1. Music is a lot like GameDev - it's a business, we create an entertainment product, and after that, it's all about getting exposure - particularly in the music industry: if nobody hears your music, or sees your game, then it's very hard to sell it. At this point in the product development, almost any advertising is good advertising, it's not about making money from the work of others, but I agree that it's important to have a contract which is both mutually beneficial, and states clearly the interests and liabilities of both parties.
  2. leith

    FrameBuffer / Multi light

    This is, essentially, what you should be doing! There is no limit to the number of lights you can draw in deferred rendering, but there is a cost to draw them (very cheap shader), the final lighting computation works per pixel on the result of ALL lighting, not per light, so costs for drawing lights are relatively low! We can have hundreds, or thousands of lights, per frame. The next bottleneck is materials.
  3. If you know some bands, they will likely love your offer to expose their music! You may not require a publishing deal to use music, if you ask the guys who create it, and if they like your game.
  4. leith

    FrameBuffer / Multi light

    Yep, but you also need to clamp its intensity, and deal with some way to mix the colours of the lights, whichever suits you - we have some options here, it's not as simple as adding numbers and clamping to 1
  5. leith

    FrameBuffer / Multi light

    The idea for 'drawing lights' using deferred rendering is rather different to other lighting techniques - for each light, you need to actually draw a mesh, whose shape and size correspond to the 3D volume of the light - for a point light its a sphere, and for a spotlight, its a cone - directional lights are handled separately. I would recommend this very old tutorial :see #35, 36 and 37 - its not a perfect solution, but it will help you to understand how the lighting phase works in deferred rendering.. I once used it as a basis for a more complete deferred renderer, which was used my bachelor degree final project, the logic is fairly sound.. effectively, for each pixel which represents a solid point on a surface, we accumulate in one of our gbuffer textures, the influence of all lights in the scene whose volume contains the point in worldspace representing that pixel - we don't do the full lighting calculation, we just gather the intensity (and colour) of all lights that fall on a pixel, we DEFER the final lighting calculation... and once we've processed ALL lights, we do a final pass, and using all the knowledge of all our gbuffer textures, we do the final lighting calculation per pixel for the output texture. BDRF (bidirectional reflection distribution function) is used for a specific surface material effect, and can be added later, as it is material-specific, your garden-variety 'Lambert' shader can be written as a first step. http://ogldev.atspace.co.uk
  6. Your hardware's shader model may have a limit on the number of textures that can be accessed in a single PASS, but most (modern) scenes require multiple passes. If you're changing geometry and texture at the same time, there's really not much overhead to draw stuff using multiple passes - however I wonder why you need so many textures, have you considered using a texture atlas / megatexture approach?
  7. leith

    AI and Machine Learning

    I'd be glad to share my insight and experience with neural networked AI, including purely genetic / adaptive AI (which require no formal training data in order to improve themselves), but you know what? For most games, FSM are adequate, behaviour trees are awesome, you don't really need to get too carried away, and if you do, you can always add a bit more script.
  • 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!