Revision 79e1e92d
Added by danij about 13 years ago
Added by Files
- added
- modified
- copied
- renamed
- deleted
- doomsday
- engine
- api
- data
- portable
- include
- m_vector.h (diff)
- mapdata.hs (diff)
- p_maptypes.h (diff)
- p_objlink.h (diff)
- r_data.h (diff)
- r_lgrid.h (diff)
- r_lumobjs.h (diff)
- r_textureprojection.h (diff)
- r_things.h (diff)
- r_util.h (diff)
- r_world.h (diff)
- rend_main.h (diff)
- rend_shadow.h (diff)
- src
- bsp_map.c (diff)
- edit_map.c (diff)
- gl_texmanager.c (diff)
- m_vector.c (diff)
- p_dmu.c (diff)
- p_objlink.c (diff)
- p_polyob.c (diff)
- p_surface.c (diff)
- r_data.c (diff)
- r_lgrid.c (diff)
- r_lumobjs.c (diff)
- r_main.c (diff)
- r_textureprojection.c (diff)
- r_things.c (diff)
- r_util.c (diff)
- r_world.c (diff)
- rend_list.c (diff)
- rend_main.c (diff)
- rend_shadow.c (diff)
- include
- plugins
- engine
Store tangent and bitangent vectors in (map) surface_t.
For the purposes of lighting an decoration projection, these vectors
are frequently needed and by not storing them, it means repeatedly
calculating them each time they are needed. These vectors are needed
often enough that storing them along with the normal makes sense.
Updated surface debug display to draw all tangent space vectors.
Project simple mobj shadows similar to dynlights
This approach to drawing the shadows can naturally result in rather
a lot of overdraw. The upside however is that there far fewer visible
artefacts than the older algorithm. Neither is ideal so my current
plan is to implement a heuristic analysis of a mobj's shadow-casting
properties to determine which algorithm to use in a given situation.
In practice this will be pretty simple; close and large shadows use
the accurate method, others use the simple method.
The old algorithm for mobj shadows has been disabled temporarily.