{"push_id":3062469334,"size":7,"distinct_size":1,"ref":"refs/heads/ge_map","head":"d44f038a3d9551f1919f257093ae678a20ae401d","before":"d06056b44e2a1034f6ffeb2905b04d1b4e3b2a32","commits":[{"sha":"ea1ffff9e6f099f373282dba2b4591ad1422954d","author":{"name":"Porteries Tristan","email":"bc4c45b520458c245d6c1c76f422f9a22df3d4ad@gmail.com"},"message":"UPBGE: Fix batching uvs and colors.\n\nThe uvs and colors were merged at the wrong place (begining of the vector)\nbefore.","distinct":false,"url":"https://api.github.com/repos/UPBGE/blender/commits/ea1ffff9e6f099f373282dba2b4591ad1422954d"},{"sha":"9f54aab55a336afbb6f1934946eb8ca64601c2d3","author":{"name":"tristan","email":"2be88ae07a73b8c2a75656d36b1412903f7f78b8@upbge.org"},"message":"UPBGE: Fix modifier deformer normal recalculation.\n\nBefore if an object was using a modifier and armature deformation\nthe deformer BL_ModifierDeformer was created and during an Update\nthe armature mesh was first updated. But the function responsible\nto update the armature mesh is also recalculating the normals. But\nthe derived mesh can have an higher number of vertices and so the\nupdate of normals was based on an incorrect number of vertices which\ninduced memory overflow.\n\nWhen updating a derived mesh, then normals don't need to be updated.\nIn this case BL_SkinDeformer::UpdateInternal should informs\nBGEDeformVerts or BlenderDeformVerts to not update normals.\nThis is achieve by introducing a \"recalcNormal\" argument to functions\nUpdateInternal in BL_SkinDeformer and BL_ShapeDeformer levels.\nWhen the update is directly proceeded from one of these classes,\nrecalcNormal is to true, if they are updated through top BL_ModifierDeformer\nrecalcNormal is to false.\n\nFix issue: #862.","distinct":false,"url":"https://api.github.com/repos/UPBGE/blender/commits/9f54aab55a336afbb6f1934946eb8ca64601c2d3"},{"sha":"dfb83b57e0ca5f4451122e3eadc732f9a784df37","author":{"name":"tristan","email":"2be88ae07a73b8c2a75656d36b1412903f7f78b8@upbge.org"},"message":"UPBGE: Fix mouse release event with multiple logic step per frame.\n\nPreviously when the frame was slow enough to trigger multiple logic\nstep, then the mouse movement events were wrongs, activated and\ndeactived everytime.\n\nThe release events are faked when the event consumer didn't receive\nan event for the current frame, this is proceeded in function\nSCA_IInputDevice::ReleaseMoveEvent.\nBut this function was called at every logic step and the dispatch of\nevents is produce between every frame not logic step.\nThis caused to always set fake release events because it was impossible\nfor the second logic step to get new mouse events.\n\nTo fix this issue, ReleaseMoveEvent is called only once per frame.","distinct":false,"url":"https://api.github.com/repos/UPBGE/blender/commits/dfb83b57e0ca5f4451122e3eadc732f9a784df37"},{"sha":"51e8bf4798a5acb826a70a1c13ca8457128a7ad6","author":{"name":"lordloki","email":"bcef897b93f0c71b89638f118fc88c11b39c8776@gmail.com"},"message":"UPBGE: Fix for mouse actuator return value (#907)\n\nNow it works perfectly when activating from an always sensor.\r\n\r\nAdditionally, it introduces a boolean check for initial skipping instead the modifying the oldposition.","distinct":false,"url":"https://api.github.com/repos/UPBGE/blender/commits/51e8bf4798a5acb826a70a1c13ca8457128a7ad6"},{"sha":"d138c81b87f4f3469907358f912114dbcfc5114a","author":{"name":"tristan","email":"2be88ae07a73b8c2a75656d36b1412903f7f78b8@upbge.org"},"message":"UPBGE: Fix KX_SteeringActuator.navmesh assignement.\n\nThe type check for the assigned object is fixed.","distinct":false,"url":"https://api.github.com/repos/UPBGE/blender/commits/d138c81b87f4f3469907358f912114dbcfc5114a"},{"sha":"b387a7f3d1e42a49bac509766438c43c64ab312b","author":{"name":"tristan","email":"2be88ae07a73b8c2a75656d36b1412903f7f78b8@upbge.org"},"message":"UPBGE: Fix duplication of navigation mesh objects.\n\nThe duplication of navigation mesh was processing a regeneration of the mesh\nand a registration to the scene in the function BuildNavMesh. But the caller\n(ProcessReplica) is on an object without a scene graph node and so an access\nto its scene, this mean that the try to register the nav mesh in the scene\nobstacle simulation failed in BuildNavMesh because the scene is unreachable.\n\nTo fix this issue the management of obstacle simulation for nav mesh and\nobstacles is fully moved into KX_Scene::AddNodeReplicaObject after the new\nobject ensure a scene graph node.\n\nFix issue #926.","distinct":false,"url":"https://api.github.com/repos/UPBGE/blender/commits/b387a7f3d1e42a49bac509766438c43c64ab312b"},{"sha":"d44f038a3d9551f1919f257093ae678a20ae401d","author":{"name":"tristan","email":"2be88ae07a73b8c2a75656d36b1412903f7f78b8@upbge.org"},"message":"UPBGE: Refactor texture renderers and fix planar and stereo.\n\nOne common issue of the texture renderer is the management of multiple\nviewports (as for stereo). For renderer as cube map it doesn't matter\nbecause none data from the viewport (view, projection) is used for the\ncube faces, but planar does. Planar renderer use the camera of the\ncurrent viewport to figure out a mirror view matrix and use a projection\nmatrix near to the one of the viewport.\n\nIn case of stereo a planar renderer must be rendered twice for the both\nstereo viewports. Previously it was achieved by separating the planar\nin dependant renderer category and render this category in each viewport\nrender (RenderCamera function), but it implies to interrupt the render\nof the viewport by unbinding its off screen.\nAlso in futur it would be interesting to create all the render data\nand execute all the renders after without determining for who the\nrasterizer is rendering.\n\nAt first point, the planars will all be rendered before the viewport\nand use unique textures that will be selected in the viewport rendering.\nEach of these textures are stored by layers (RAS_TextureRenderer::Layer)\nwhich contain the render faces (Face class). Two situations are\npossible:\n- the renderer shares its layers along viewport, only one layer is\n  available.\n- the renderer use a unique layer per viewport.\n\nThe function RAS_TextureRenderer::EnsureLayers constructs the layers\nif needed and return the usage of the layers : shared or unique.\n\nWhen a layer is created, its constructor create a new GPUTexture\nusing the bind code from GPU_create_gl_tex and passing it to\nGPU_texture_from_bindcode. Finally the texture is attached to the\nframe buffers of the faces.\n\nThe renderer manager proceed the rendering per renderer, then per layer,\nthen per face. The render data changed to support this system.\nFirst of all the camera data are now stored in the scene render data\nand not per frame data. Also they are organized per eyes and frame\ndata use a list of eyes to specify which cameras could be rendered\nfor a frame. Each camera render data stores an unique index, this\nindex is used as renderer layer index.\nWhen rendering, the camera data index is passed to RAS_BucketManager::Renderbuckets\nwhich is used in fonction PrepareBuckets and KX_BlenderMaterial::Prepare\ncalling for each texture ApplyRenderer. This last function, in case\nof renderer, get the bind code of the renderer depending on the\nviewport index and copy this bind code for the next texture binding.\n\nFinally the texture users are not needed anymore in RAS_TextureRenderer\nas the renderer now create themselves the textures and changing the\nmipmapping or the anisotropic filtering explicitly call the recreation\nof the textures now.","distinct":true,"url":"https://api.github.com/repos/UPBGE/blender/commits/d44f038a3d9551f1919f257093ae678a20ae401d"}]}
{"actor":{"display_login":"panzergame"}}