利用者:Kupoman/GSoC 2013/reports

Week 1

Progress

This week I have created a feedback thread on the blenderartists forums to begin gathering ideas on the small community requested features that will be completed later in the project. The thread has gotten many replies and suggestions have been aggregated into the first post. The thread can be found here: [1] .

Furthermore, I have learned that a community member already has a patch for some level of detail (LoD) support in the BGE. After reviewing the patch and experimenting with it, I have decided to implement my own LoD system. The reasons being that I want to make sure the code is usable in both the viewport and the BGE, and I felt the UI implemented in the patch could be improved. I will likely be using the patch as reference for implementing my own system.

For this new system I have already reimplemented some new UI that allows users to add and remove LoD levels from an object. Currently these levels do not do anything.

I have also fixed two bugs from the BGE tracker:

#35447 LibLoad Meshes and Scenes causes crash of blender (closed)

#32775 LibFree crashing (waiting for response from submitter)

Next Week's Plans

Next week I intend make sure the LoD levels properly save and load, as well as take care of any relevant do_version changes. I will also begin working on the LoD selection and switching in the viewport. I also plan to fix a few more bugs next week (3-5)

Problems/Questions

None so far

Week 2

Progress

This week I more or less finished getting the level of detail system working in the viewport. I have also been getting more feedback on my Blenderartists thread, including issue reports that I have fixed. Both mesh and material level of detail are working. The level of detail system also works well with group instances, allowing a user to setup levels of detail on an object and instancing it throughout the scene.

As far as bug hunting goes, I have decided to hold off on bug fixing while we are in BCon4 as the bug fixes have been going straight to Trunk. However I did address one regression this week:

#35811 Blenderplayer crash on closing if file saved with an actual version (waiting for response)

I have also began putting together a demo scene for the level of detail system, though there isn't much to show there yet.

Next Week's Plans

Next week I should be able to at least mostly get the level of detail system working in the BGE, at least for mesh and material levels of detail. I also plan to make some progress on the demo level so users have a good file to test the changes with.

Problems/Questions

I have been running into several problems when trying to assemble the demo scene. I wanted to develop a way to procedurally place trees for a forest level, however I ran into some problems with the script to do so.

First of all bpy.ops.object.add_named and bpy.ops.object.group_instance_add cause Blender to crash (looks like something to do with the 3D cursor). I was able to work around this by specifying a location for group_instance_add (even if it was the default value).

Furthermore, adding many objects with group_instance_add becomes impractical as each object takes approximately 2 seconds to add by the time you reach 3,000 objects. I have not yet determined if the time complexity is linear or exponential, but it certainly is not constant.

I have also been running into problems rebuilding my non-development version of Blender. This is because I have been using vc2010 and SCons for this, and vc2010 support was recently dropped. When trying to build with SCons and vc2012 I have run into build errors about bool/true/false macro redefinitions. I finally just pointed my shortcuts to a cmake build and continued working.

Overall, things are going well and I am still on schedule.

Week 3

Progress

The level of detail system now works in the BGE for meshes and materials on both regular objects and dupligroups. More testing will be needed to determine how well the level of detail system works with libloading. I have also created an operator that will automatically setup levels of detail on a selected object based on the object's name.

I ended up not working much on the demo level, so that will have to be moved to next week.

Next Week's Plans

My timeline had allocated up to four weeks for working on the level of detail system, so I will take that fourth week to further test and polish the system. I also plan to work on some documentation and demos for the system.

Problems/Questions

Things are going well :)

Amendment

To clarify, the script will search the scene based on the selected object's name, and try to setup the lod levels based on the names of other objects. Naming conventions that work with this script are any that begin or end in LOD# (where # is the number of the lod level with 0 being the highest detail object). The key term is case insensitive, so you can use lod# or LOD#. The key is to be consistent so the script can find your objects. I will write up some more detailed documentation on this. I just wanted to make sure people did not think that this script will automatically create the necessary objects for lower levels of detail.

Week 4

Progress

I have added an operator to generate levels of detail using the decimate modifier, as well as continued to make minor touch ups to the level of detail UI. I have also created documentation for the level of detail system and it has been posted on my wiki page: [User:Kupoman/Level_Of_Detail]

I have also created a demo scene, but I want to make some changes to it before distributing it (add credits etc). The scene is simple, but should be enough to demonstrate the level of detail system in action. I will respond to this email once I have uploaded the demo, and I will put a link to it on my feedback thread.

Next Week's Plans

Bug Fixing! I am hoping to close 10-15 bugs next week. Unless I feel they are critical bug fixes, I may commit them to a staging branch or collect patches until we enter BCon 1.

Problems/Question

Not really a problem or question, but I would like to mention that I will be looking to merge the level of detail system into Trunk during the next release cycle. Since I will be focusing on bug fixing for the next few weeks, it should be easy to merge in just the level of detail system from my GSoC branch.

Demo Link

https://dl.dropboxusercontent.com/u/10900837/lod_demo.blend

Week 5

Progress

This week I have been tackling the BGE bug tracker.

Closed 3 duplicate bug reports:

#36114 Wrong materials when modifiers in use

#35951 Standalone crashes when "start game from a file"

#32383 Baked normal maps distort on rigged meshes

Committed fixes for 4 bug reports:

#35195 Shadow Only lamps only work with Specular enabled

#35563 Object colour setting for objects and fonts not using colour management like materials

#34317 Navmesh with empty mesh

#33016 Blender crashes when I start the game engine

I had committed a fix for:

#36223 Strange page fault of "Game" actuator

But have since learned that the fix needed to be done better, so I am taking another look at the problem.

I will be closing the following 4 reports unless more feedback is provided:

#35693 GOD rays is not working in blender 2.67b

[https://projects.blender.org/tracker/index.php?func=detail&aid=32906&group_id=9&atid=306 #32906 DDS texture is repeating when it should not

#31196 Crash after using reinstancePhysicsMesh function

#20477 Mesh that makes framerate 4x slower when OUT of view Reasons why are given in the individual reports.

I am also currently investigating some reports regarding UV and color channels in the node system. There are several reports on this with some reports being partial duplicates of others.

That leaves the total at 7 closed with 5 on track to be closed (I intend to get a proper fix for 36223 tonight).

Next Week

10-15 reports closed (not including the 4 to be closed from this week)

Questions/Problems

All good :)

Week 6

Progress

More BGE bug tracker work.

Committed fixes for 3 reports:

#21488 Pumpkin in Gamekit Tutorial flips upside down

#29575 Object not drawn in game engine

#18804 Shadow type faces cast onto invisible faces (non-GLSL)

Closed the following 7 reports for the reasons noted in the report:

#29912 TypeError on reading SCA_JoystickSensor.axisSingle

#27693 Mirror Modifier breaks GLSL material in BGE (backward problem, 249 worked great)

#17853 getReactionForce() returns [0,0,0 when using Bullet]

#31385 Vertex colors layers does not work in game engine

#23772 GameEngine wrong UV-Layout

#31775 Nodal Material Forces UV-Map

#19291 Node materials don't support multiple VColors and UV in BGE

Flagged the following 2 reports for closing in one week for reasons noted in the reports:

#34642 Physics type Character

#18643 Blendin fails when previous action has different channels keyed

I have potential fixes for the following two bugs, but I want to review them further before committing them:

#35120 BGE Camera Actuator fails to align to -X axis (Fix)

#28908 Child object wrong position/rotation due to parent object scale (BGE) [www.pasteall.org/44423/diff (Fix)]

I think this report can be closed, I am just awaiting feedback from the submitter (contacted via IRC):

#18486 "Cluster Collission SS" Compatability Issue with GE softbodys

I have also been investigating and reporting on various other reports in the BGE tracker with less success. I have also committed a new fix for bug #36223 as mentioned in last week's report.

This leaves the total at 10 closed with 5 potentially being closed soon.

Next Week

10-15 reports closed

Questions/Problems

I may need to start consulting other developers as I am leaving code I am familiar with as I continue to hunt down bugs. Otherwise, things are going well.

Week 7

Progress

I started this week by doing some touch up on the level of detail work from earlier this summer and submitting a patch for it to the code review site:

https://codereview.appspot.com/12216043/

Overall bug hunting this week didn't go so well.

Added some documentation to the wiki to close 2 reports:

#26391 Collision sensor fails to get triggered when colliding a Softbody in GameEngine

#29792 bge.constraints 6DoF parameters (stiffness,damping,angle limit) has no/strange influence

Closed the following 3 bug reports for the reasons noted in the reports:

#27265 2.57b GE: Updating of debug Property display from linked scenes not working

#32767 Object Properties do not hold correct values

#36329 Character physics type doesn't react to actuator?

I have investigated 6 other reports:

#29474 getScreenRay returns wrong objects with orthographic camera

As far as I can tell, this should work. However, adding a glReadPixels to get the depth buffer for the gluUnProject in the getScreenVect function that getScreenRay relies one does appear to correct the problem. The problem with this solution is that glReadPixels was originally removed from this function to fix another bug, and it also causes an OpenGL sync that would be best to avoid.

#32175 bge.texture.ImageRender alpha channel returns 255 for every pixel

This bug requires the use of a framebuffer with alpha bits. This feature was added, but later removed in order to fix a bug. I have not yet done the necessary follow up to figure out if we can have a framebuffer with alpha without introducing bugs.

#32470 localPosition giving world coordinates

This one seems kind of nasty. When a parent child relationship is converted, the child's local transforms are not set. However, setting the value during conversion seems to cause extra transformations to occur so that the scene may not match between the viewport and the game engine, which would be confusing and would break some existing set ups. I could have screwed up the math here, so another look could be worthwhile.

#33215 KX_MeshProxy.transformUV() argument ValueError

Fortunately this one looks simple, I just need to get in contact with Campbell to ask him some questions about the features that raise the error described in the report.

#35454 Setting parameters on joints with softbodies causes blender to crash

This one occurs because the constraint wrapper only half supports soft bodies. It will set up a relationship with a soft body, but it is not a constraint and therefore returns an invalid constraint id to the wrapper. Then when the wrapper tries to use the invalid constraint id, the crash occurs. I have a patch that raises python exceptions whenever the wrapper tries to perform an operation with an invalid id (and notes that this occurs with soft bodies), but I am not sure yet if this is the best approach to handle this report.

#18987 alignAxisToVect() Factor Bug

We seem to have a lot of reports like this one. Not really a bug, but something should probably be done. I have a patch that adds a note to the function's documentation that points out that factor can cause undesired behavior at angles near 180 degrees. I spent some time today figuring out how to generate the docs to test my patch, and now I just need to double check if this is the way we want to deal with this report.

For these reports I will be talking with my mentor and some of the other developers to see how to best resolve them.

I have also flagged the following 2 reports for closing in one week for the reasons noted in the reports:

#19016 "Real" armature modifiers not working

#19277 Mesh deform in views but not in game player, armitage moves parented objs though

This leaves only 5 reports closed with 8 in progress. There were other reports that I looked at but I didn't start recording incomplete reports in my log until later in the week, though I did post comments in reports as I made discoveries. I spent a fair amount of time digging through game engine's physics code trying to solve bugs, but I did not have much success there (though I got a good tour of that part of the code base chasing these bugs).

Next Week

Since I am not doing so well with the bug hunting, next week I will work on some of the community requested features. The first one I plan to work on is getting the displace modifier working in the blenderplayer (this is also reported as a bug). This requires some code reshuffling that could potentially lead to procedural texture support in the game engine. I plan to investigate the feasibility of adding procedural texture support, and if it looks reasonable I will work on that. Otherwise I will move on to other requested features as deemed appropriate by my mentor and other BGE developers.

I also plan to follow up on some of the investigated reports mentioned in the progress section, especially the last three listed.

Questions/Problems

See the investigation results above :P I will also be contacting some people specifically about some questions.

Hopefully next week is more successful.

Week 8

Progress

I started this week be investigating the displace modifier in the player and supporting procedural textures. The reason the displace modifier does not work in the player is because the displace modifier relies on the render module, which is not linked with the player. A large chunk of the stubs.c file is for the render module, so linking it could simplify that file. However, that alone does not seem like a good enough reason to link against the render module. This is why I was looking into procedural textures, to see if the render module could be used for something else. However, the procedural textures do not look like they would work well for most mapping types with out a lot of work (converting them to shaders). Generating a texture and passing it into the shader system however is fairly strait forward.

Other than that, I have began working on point light shadows as they were one of the community requested features. I am using a technique called Virtual Depth Shadow Cube Texture which will provide flexibility for multiple lighting techniques, including those using depth textures. I have the rendering into the virtual texture and generating an indirection cube map. However there are still some math errors and other oddities to resolve. In other words, good progress has been made, but there is still some work to go.

I also added a fov attribute to KX_Camera as a community requested feature.

There has also been some minor progress regarding some of the bugs from last week:

[#33215] KX_MeshProxy.transformUV() argument ValueError:

This bug has now been corrected and closed.

[#32175] bge.texture.ImageRender alpha channel returns 255 for every pixel:

This bug will require a user option to enable an alpha frame buffer.

[#18987] alignAxisToVect() Factor Bug:

After talking to Campbell, he and I decided that this bug should be fixed, and not simply documented as a limitation.

Next Week

I plan to get the point light shadows finished, and begin looking at improving our existing shadow support. This includes the option to control the blur factor of the variance shadow maps and potentially looking into some better filtering and performance improvements for variance shadows. I would also like to look into techniques for making sun shadows work better over large areas such as cascaded shadow maps or parallel split shadow maps. I am not sure how far I will be able to get on those improvements, but I will try to get as much of it done as I can.

Problems / Questions

All good.

Week 9

Progress

I have been hesitant to commit to my branch, since the LoD system is currently under review, and I want to make the transition to Trunk as smooth as possible. For now, I am stashing changes in patches.

Point light shadows are now mostly working, though there are still some artifacts along the edge of the cube map I am having difficulties getting rid of. Other than that, they work correctly with both simple and vsm shadows. The patch so far: http://www.pasteall.org/44889/diff

I also investigated controlling the blur effect on vsm shadows. Increasing the blur effect causes banding to appear at higher resolutions, and would likely require user control of the number of samples. We could potentially edit the shader before compiling it to change it for the number of samples. There is also a samples option from the render system's shadows that we could reuse for this. Adding an option to toggle soft shadows would be simple, and could be useful as a large amount of the time spent rendering vsm shadows is in the blurring step.

I experimented with some different filtering options on vsm shadows. I was unable to get mipmapping to do anything for the shadows, however I did have some luck with anti-aliasing with MSAA. Anti-aliasing the shadows provided visual improvement with minimal resource cost on low settings (2x-4x). However, the visual improvements are only noticeable on low resolutions when no blurring is being done. This could be a useful option if we add an option to toggle soft shadows.

Patch: http://www.pasteall.org/44890/diff (has some hard coded values that will need to be cleaned up)

While experimenting with the image format on the vsm render targets, I noticed the values stored in the render targets appear to be unsigned normalized values. This means they can be stored in an integer format instead of a float format. Unfortunately, integer formats only go up to 16bits of precision, whereas vsm shadows are currently using 32bits. Switching to 16bits causes some artifacts to occur, but they can be mostly handled through the bias setting. I believe there is more information in the vsm literature that addresses precision issues. Some of these techniques may allow us to use the RG16 image format with minimal visual degradation.

Patch: http://www.pasteall.org/44891/diff (it's a tiny one)

I have spent some time reviewing literature regarding cascaded shadow maps. I think I understand the technique now, and have begun trying to fit the lamp's frustum around the view frustum. I have been able generate the view frustum corners to find the bounds of the view frustum, though something seems strange when I try to adjust the light frustum based on this information. For now I have just been experimenting in the light drawing code. Next week I will try it with actual shadows.

Next Week

I plan to get the cascaded shadow maps finished, and hopefully track down the cause of the artifacts found in the point light shadows. I will also be addressing some comments from the level of detail code review.

Problems / Questions

None.

Week 10

Progress

Cascaded shadow maps have proven to be a little more difficult than I originally thought. The idea is simple, but finding clean ways to implement parts of the code in Blender has been a bit of a problem. However, I have made progress on cascaded shadow maps. The cascades are being properly rendered to a single texture atlas, and I have created a shader that can read the appropriate cascade from the texture atlas. Furthermore, I have created new UI to control the number of cascades (1-4). Unfortunately, there appears to be a problem with the cascades closer to the camera (the last one shadows correctly). The matrices corresponding to those cascades are handled a little differently, so they may not be correct or not correctly transferring to the shader.

I also spent some time getting Git setup on Windows and created a Git branch (I didn't want to create yet another SVN branch) to store shadow improvements in instead of patches. Currently I have the cascaded shadow maps and point light shadows in that branch.

The branch was created from Moguri's svn clone to avoid the hours required to set up such a clone myself: https://github.com/Moguri/blender/tree/shadow_improvements

Next Week

I have spent longer on shadows than I wanted to. However, I feel one more week could really help get all the work polished up. I will see what I can do get cascaded shadow maps fully working as well as point light shadows (haven't had a chance to look at that artifact yet). As well as bringing in some of the other improvements/research from the previous weeks. After next week, I will stop working on shadows and go back to tackling bug reports from the BGE tracker.

Problems / Questions

Not much other than going too far down the rabbit hole. I may need some help finding a way to pass some camera data into the shadow shader code. We'll see if I can figure something out (there are currently a couple of hard coded values).

Week 11

Progress

Point lights are working pretty well now, and the seam artifacts have been resolved. I have also added options and UI for disabling the blurring on VSMs, using a lower precision (and higher performance) image format for VSMs, and the option to use front face culling for shadows (which can result in fewer self shadowing artifacts, but fails to cast shadows of objects that are only front facing polygons such as planes). This work has all been committed to the git branch mentioned in last week's report: https://github.com/Moguri/blender/tree/shadow_improvements

Cascaded shadow maps are still a little bug (especially in the viewport) but are mostly working.

Next Week

Next week I am returning to the BGE bug tracker. I will try to work on some of the various ATI bugs using my laptop (ATI 6630m) and another computer I have access to that has an older low end ATI card. I am hoping to close 5-10 reports (some of them might take some time).

Questions/Problems

Things are going well.