The ultimate goal is to only allow the rasterizer to handle OpenGL and bf_gpu
calls. This commit creates a RAS_ILightObject interface and a RAS_OpenGLLight
implementation.
GPC_Canvas::GetWindowArea() and KX_BlenderCanvas::GetWindowArea() are tracking two
different things. The 2d filter system doesn't actually need the window area and
can get by just using the viewport dimensions, which it now does. The GetWindowArea()
mess should probably be cleaned up.
This reverts commit 6a473305af22468abfc4c4f8f3002dc0a97fffd7.
Caused T38296, need to investigate this further but for now
better not leave blender in unstable state.
This mode is designed for passive 3D TV: the viewport is split
horizontally - left eye above, right eye below - but the original camera
viewport is squashed in each half (with half the vertical resolution).
This is necessary to restore the aspect ratio in the 3D output because the TV expands each half to the full screen size.
Disabling display lists for legacy ATI cards since they don't support display lists well.
Also removing an unused variable from the display list rasterizer.
This commit fixes two different issues, which were caused by
how weights are being calculated for relative shapekeys.
Weights for key block used to saved in KeyBlock DNA structure,
which lead to situations when different objects could start
writing to the same weights array if they're sharing the same
key datablock.
Solved this in a way so weights are never stored in KeyBlock
and being passed to shapekeys routines as an array of pointers.
This way weights are still computed run-time (meaning they're
calculated before shapekey evaluation and freed afterwards).
This required some changes to GameEngine as well, to make it
never cache weights in the key blocks.
Another aspect of this commit makes it so weight for a given
vertex group is only computed once. So if multiple key blocks
are using the same influence vertex group, they'll share the
same exact weights array. This gave around 1.7x speedup in
test chinchilla file which is close enough to if we've been
caching weights permanently in DNA (test machine is dual-code
4 threads laptop, speedup measured in depsgraph_mt branch,
trunk might be not so much high speedup).
Some further speed is optimization possible, but it could be
done later as well.
Thanks Brecht for idea of how the things might be solved in
really clear way.
--
svn merge -r58786:58787 ^/branches/soc-2013-depsgraph_mt
Any GLSL materials loaded after lights are LibLoaded will now use the lights in
heir shaders. This includes materials loaded from the same scene as the LibLoaded
lights. We could later add a new flag to LibLoad to recompile all existing shaders,
but this commit should offer a lot more flexibility as is.
The BucketManager was assuming that all modified meshes were rendered when a render pass completed. However, materials that did not cast buffer shadows did not render during the shadow rendering step, and thus were never updated.
If the "Framing" mode is set to extend,
the camera frustrum changes when you
resizes the blenderplayer window.
Before this patch, there were no way to
control which part of the framing you want
to extend (vertical, horizontal or arbritary).
Now:
If the camera sensor fit is set to HORIZONTAL,
the horizontal field of view doesn't change.
If set to VERTICAL, the vertical fov doesn't change.
If set to AUTO the old behaviour takes place, arbitrarly
showing more of the horizontal or vertical field of view
depending on the aspect ratio of the window.
Test file:
https://svn.blender.org/svnroot/bf-blender/trunk/lib/tests/gameengine/framing_extend.blend
Bugfix supported by NF-UBC Nereus Program as part of the development
of OceanViz/NereusViz
