Jump to content

mockingbird

Members
  • Posts

    11
  • Joined

  • Last visited

Blog Comments posted by mockingbird

  1. In a renderer designed to run on everything, it's useful to have a distinction between CSG and model geometry. CSG geometry forms the "background" of the scene and is very cheap to render, since no lighting information has to be calculated. If you look at Left 4 Dead 2, the dynamic lighting only affects the models as well. They put a lot of model geometry into the scene, and you don't really notice when you're getting eaten by zombies. If it's good enough for Valve, I think it's good enough for our basic renderer.

     

    It's not really worth it, IMO, to worry about physical accuracy of light when you just want something that runs everywhere. The new deferred renderer will provide very realistic lighting, and the basic renderer is intended to provide a fallback for hardware that can't handle high-end graphics. If it turns out a lot of people absolutely need dynamic lights to affect CSG brushes, it's pretty trivial to add, but I don't want to make spur-of-the-moment design decisions.

     

    Likewise, models do not self-shadow because they just use vertex lighting. I don't think it's worth putting a lot of effort into making a better "fake" lighting system when we can put that effort into writing a new deferred renderer. The basic renderer is meant to run fast on everything, not provide physically accurate lighting.

     

    Now, I can add CSG normal maps by baking the light direction into the lightmap. The challenge there is I want to store the light vector in the alpha channel of the lightmap, not in the RGB components of a second texture. It's not perfectly accurate, but it looks good. (Again, Source Engine uses this approach.)

     

    Josh, source engine bakes directional lightmaps which stores light direction into a RGB channel, this is useful to fake dynamic lighting on static meshes (as CSG brushes) and even compute lighting dynamic on moving entities veary cheaply as the light direction is already computed. The only downside is that light sources must remain static (never moves). Directional lightmaps doesn't need to be as big as lightmaps. You can have as many detailed lightmaps in a big scene and few or even only one directional lightmap per level.

    And i agree with the Source approach, if you can mimic the source engine, you will have a very good renderer that runs everywhere.

    A defferred renderer won't run on current mobile devices it is too bandwith hungry. Maybe in a two years when the iPad4 will be the lowest thing you can get on a tablet then maybe you'll have good chances to write a defferred rendering for it. Otherwise, stick with the Source way.

    Even in a forward renderer you can compute multiple lights in the same pass and you automatically switch their positions in the shader (for each dynamic object affected by lights). For example you let the user chose how many dynamic lights should any entity be affect by (to a maximum of 4) and switch lights position in the object shader. If i remember well, source engine does exactly this with dynamic entities. Unless you really want to see tons of lights moving in a game (hich is really rare), i don't see any urgent need for a defferred renderer.

    • Upvote 1
  2. I've today upgraded my LW2 license to LW3 and LW3iOS (300$ total) which is a bargain and you'll see how quickly it pay off to offer agressive low prices. ;)

     

    We've spend 7500$ in Unity4 licenses and will soon become obsolete when v5 arrives next year. That's painful. We will possibly stick all the way with LW if version 3.2 comes before our current project is done and forget about Unity for a while. Unity start to become really expensive. Plus the fact that i can finaly code nativelly in C++, more reasons to stick with LW3!

     

    Yeah, definatelly we need a how to videos/tutorials in the comming weeks.

    PS: Waiting for my invoice to be completed. tongue.png

×
×
  • Create New...