Used the engine's RemoveScene (which ultimately calls the converter's RemoveScene) instead of the converter's RemoveScene when the converter free a blend file. This handles the scene removal in a safer fashion and solves the crash described in part 2 of the bug report. Part 1 no longer appears to cause a crash.
The embedded player was calling glPolygonMode(GL_FRONT_AND_BACK, GL_FILL) before rendering font objects, but someone forgot to add this to the Blenderplayer.
KX_BlenderSceneConverter's destructor freed the contents of several std::vectors without removing those contents from the vectors. Later these vectors are iterated through. Making sure the vectors get cleared solves this problem.
This fix is mostly based off of HG1's patch from the bug report, which had ImageRender::Render() call KX_KetsjiEngine::RenderFonts(). However, I have moved RenderFonts() from KX_KetsjiEngine to KX_Scene where all of the other font and rendering functions are. The real fix for this mess would be to not have ImageRender::Render() have so much duplicate code from KX_KetsjiEngine::Render(), but that's a code cleanup problem for another day.
BF_PYTHON_INC can contain more than one path (in the mono-string format), don't know how this could not be found earlier, completely broke build of GE on any recent Debian/Ubuntu distro???
Was a missing NULL-pointer check. No idea why it took so long to figure
issue out -- apparently there was no crash in linux for me and msvc
didn't show any backtrace :S
Also corrected weirdo way of bit flag check which was:
!ma->mode & MA_FACETEXTURE
better do !(ma->mode & MA_FACETEXTURE) since ! is a logic NOT.
* Removing KX_Scene::RemoveAnimatedObject() since KX_Scene::NewRemoveObject() is already handling this.
* Don't create a new BL_ActionManager when replicating an object. Just set m_actionManager to NULL and let KX_GameObject::GetActionManager() allocate a new BL_ActionManager when one is needed.
* Use KX_GameObject::GetScene() instead of KX_GetActiveScene() in KX_GameObject::GetActionManager() to make sure we're using the object's scene instead of one where Python might currently be running from. This could avoid potential issues with playing actions for objects in other scenes.
consistent with projection painting.
Also did some refactoring of this code, moving the brush image creation code
out of brush.c and making it consistent with image updating code.
BL_BlenderShader was only sending over proper UV data if the current drawing mode was KX_TEXTURED. Now it also checks for (and sends data for) alpha shadows.
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.
Root of the issue was fixed by Brecht in svn rev56441.
This change only prevents crash of files created in
blender before that fix, and also gives more useable
information about what's wrong (apparently, assert
here was doing nothing).
* 2D image painting support for masking to limit the max contribution of a stroke
to a pixel, to get it working compatible with projection painting. Not strictly
a bugfix, but the inconsistency here was annoying.
* Fix python errors in Texture Mask panel in image editor, was missing overlay
options.
* Clamp paint mask to 0..1 in case some texture exceeds it, this could give black
pixels due to integer overflow.
Blender's old default of 1 was too small here.
Now we don't override the default.
If it's really needed to use a smaller value here, the property should
be first exposed in the ui, but don't think this is necessary.
Fixes [#35076] Dynamic objects have periodic glitch in velocity when on an incline
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
window, the game would stop drawing in the first and mess up the OpenGL state of
the second.
Also fixes glPushAttrib/glPopAttrib getting out of sync in some cases.
now, with a 'resize' routine for the engine we can/should also recreate some
buffers that are created only at init time (e.g., 2d filters, dome fbos, ...).
This bug was always present in Blender (since 2.49 at least).
Bugfix supported by NF-UBC Nereus Program as part of the development
of OceanViz/NereusViz
