User:Dfelinto/Foundation16

From BlenderWiki

Jump to: navigation, search
Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

[edit] Week 38 (Aug 8th)

Info

I arrived at the institute this week, so this is ground zero week again. After setting up the computer I wrap up some CUDA related fixes for baking before getting into multiview.

For multiview I made Multiview OpenEXR load to work in Linux (there was a bug in my code, but it worked in OSX), refactored the image_save_doit routine, and while at there designed a new option to export pre-baked 3D images. Meaning you can export anaglyph, interlace, ... straight from Blender. This was not in the roadmap, but it's something that will be necessary for Sequencer (and something users have been asking since the day 1). As of now the currently exportable modes are: Anaglyph (all modes) and Top-Bottom. Modes remaining: Interlace, Side-by-Side, Blu-Ray.

I also finished up the design for the 'Editor FullScreen' (aka clean fullscreen, aka the new fullscreen) and did some changes. The remaining part of the implementation is to add a new action zone in the top right corner (that shows only when mouse is nearby) that exits the fullscreen mode.

Multiview Main Commits
  • 3051dee - Top-Bottom Stereo Output mode
  • 737e70e - All anaglyph stereo output modes working =)
  • 09c6b31 - New Stereo Image Output options (work in progress)
  • f230d15 - fix for exr images not loading in Linux
Patches waiting for final testing
  • [D690] Fix T41222 Blender gives weird ouput when baking (4096*4096) resolution on GPU
Patches in progress
  • [D678] Fullscreen Editor (new fullscreen mode for clean UI)
Next Week

Mostly, moving on with the multiview targets. Meeting with Jeroen Bakker and Lukas Toenne to discuss about compositor changes. Finish stereo output modes. And either start with the compositor refactor, the overscan in compositor or one of the drawing in the viewport tasks. And bug fixes ...

[edit] Development Hiatus

[edit] Week 37 (May 26th)

Info

This week was spent wrapping up baking for 2.71 (apart from the [D547] patch we are release-ready) and doing important work in multiview. 3D Drawing is now correct, glitch free, and that's a big improvement. Image Editor was also taken care of and it's very robust at the moment. Last I implemented Pivot for the builtin stereo camera and now I consider the builtin stereo camera (as known as basic stereo camera) fully implemented. That included a fix for the Toe-in method. I also made sure compositing is working again (it was working before but the Image Editor bug was preventing the results from being seen). The only task I was planning to do that I didn't have time to finish is the per-window stereo setup and the full editor patch. The latter has a patch half-working already, and the former a [final design] I can know implement.

Master Commits
  • 2a9efa4e - Bake-API: Support for batch baking
  • 50a7843a - Bake-API: replacing some MEM_callocN by MEM_mallocN
  • 2057a3a2 - Proper fix T40156 Cycles Baking and applyRotation issues
Multiview Commits
  • 633f55ac - fix for drawing glitches when stereo was on
  • 029938fb - fix for crash when baking
  • 4bd686cc - Pivot for built-in (as know as basic) stereo camera
  • e480f93e - Image Editor: set COMBINED as default passtype and fallback iuser settings when changing image
Patches waiting for review
  • [D547] Bake-API: new approach for cage
  • [D546] Bake-API: allow custom UV to be baked
Next Week

Technically speaking there is no next week. Nonetheless I will keep my [Multiview wiki page] updated with the development status. For multiview what I plan next is: get 'Fullscreen Area' finished and send for review separately from multiview. Implement the 'per windows settings' as described in the wiki page. Eventually work in the compositor refactor (probably also better suit for master than for multiview, though it may make sense to wait for the 'tiles' branch to get merged). I plan to make an youtube video later with the latest changes on multiview.

As for baking I'm not sure what the future holds. A nice goal for after-2.71 would be to extend the tool to allow even more full control via Python. I foresee more feedback and [users proposals] coming after the release, and the more we can make things possible with Python, the more people can play with workflow ideas without requiring changes in Blender itself.

[edit] Week 36 (May 19th)

Info

This week I ended up fixing yet more bugs for Cycles Baking/API and adding small features (show the baked image in the Image Editor, throws warning when there is no UV). Apart from that I pushed two important commits for multiview. First is the last big of the Image Editor refactoring. Right now opened images, as well as rendered images are displayed correctly with the new UI. Second the basic camera mode (where user only gets to pick the eye separation and the convergence plane distance) is finally rendering. We had it only working for viewport, but never for rendering.

The ideal solution for that would be to change the entire rendering pipeline to take matrices instead of a camera object. However I opted for a less intrusive approach where I create two temporary camera objects (one for left and one for right), and things are working now. This has the added advantage of working for external engines as well.

Master Commits
  • 2ffe0374 - Bake-API: shows the baked image in the biggest SpaceImage around (just like Blender Internal)
  • 7f089afc - Bake-API: relaxing in the check for scale uniformity
  • dd96205d - fix T40323 Segfault on baking after rendering
  • 81b129d3 - Cycles-Bake: fix T40322 Glitch in baking a mixed SSS shader
  • d7e4a793 - Cycles-Bake: fix T40270 Combined Type fails to bake Emission node
  • 2bfc3debd - Bake-API: throws error if highpoly object(s) doesn't have uniform scale (fix T40156)
  • a8a5d68b -Bake-API: throws error if there is no UV
  • 8d297394 - Bake API: partial fix T40156 (applyRotation issues)
Multiview Commits
  • 0147d96a - Improved solution for Basic Camera rendering
  • dd7469df - Support for Basic camera rendering
  • 9c2dd855 - Image Editor fixup, now ImageUser is always initialized properly, stereo
Next Week

As we get close to the 2.71 I expect even more people to test baking and come up with new issues. At some point I would like to see the 'baking progress bar' to move during baking, but I think it can wait for after 2.71. Next multiview tasks: compositor to work again (it should be simple, I probably broke it in one of the recent refactors/merges), camera pivot, per-window stereo settings (instead of being a Use Setting), clean fullscreen mode wrap-up (it's working but it should follow the design changes discussed between Brecht, Francesco and me after last year's Blender Conference (see #17), and other open issues from github.

[edit] Week 35 (May 12th)

Info

No work week

[edit] Week 34 (May 5th)

Info

This week I focused on fixing all the bake-cycles bugs that appear in the tracker, and got multiview in a branch shape. Basically I finished what I was working last (Image Editor refactoring), merged it in the branch, merged master in, fixed conflicts, rebased the branch in logic blocks, and pushed it to git.blender.org as a 10 parts commits + the commits related to the work I did recently for BF.

Master Commits
  • 8904eaf5 - Fix T40107: painting on a psd image crashes blender + style cleanup in file
  • 8943dc60 - Bake API: selected to active needs differentials or it renders black when bump/displacement (fix T40101)
  • f194da34 - Bake API: reports were used after being freed leading to random crashes (fix T40077)
  • 14643167 - Bake API: small change, forcing Render to not have reports
  • 20c90eae - Bake API: renaming WM_JOB_RENDER_BAKE to WM_JOB_OBJECT_BAKE and use it consistently
  • 672cebf1 - Cycles-Bake: displacement support (fix T40068)
  • 31cb7e39 - Bake API: calculating differentials
  • 83cdd588 - Cycles-Bake: Subsurface Scattering support (fix T40060)
  • 08bf5319 - Cycles-Bake: Ambient Occlusion needs to be computed for COMBINED
  • d653c70e - Bake API: force opengl reload and mipmap recalc (fix T40055)
  • 2c4ea2a1 - Bake API: fix T40054 - baked image update on uv/imag editor for linear/float/noncolor, ...
  • 9fe618e3 - Fix T40048: Cycles bake crashes Blender [when there is no image]
Multiview Commits
  • 0bfc90a3 - Multiview: refactor of UV/Image editor and image flags
  • 205afa0a - Multiview: fix for crash when stereo was off
  • c7bcd631 - Multiview: support cltr+click rename for non left/right views
  • 92a1b76e...99c988ce - Multiview Base Commit 1/10...10/10
Next Week

Multiview will still be my priority for this week. I want to get rendering to work again, first for the advanced setup, then the basic one. Also in the roadmap: camera pivot (left, center, right), redraw fix, image editor passtype refresh (right now you need to select a pass type to get drawing to work well).

[edit] Week 33 (April 28th)

Info

This was the merging week. All the points presented in the review were addressed and bake-cycles work is now in master. The branch was re-organized (squashed) in logical blocks (see Final Commits below). The documentation was updated on wiki, and the API documentation was written and included in the bake_api.c file.

Documentation
Final Commits (master)
  • eec3eaba - master Cycles Bake
  • 97641a0e - master Bake API - bpy.ops.object.bake()
  • 56d8affe - master BLI_path_suffix() - new path util functon to add a suffix to a filepath (before the extension)
  • 3312b20a - master IMB buffer functions to take a mask as input
Main Commits (bake-cycles)
  • a678b014 - bake-cycles Cycles-Bake: API documentation incorporated to code
  • f5550795 - bake-cycles Cycles-Bake: using proper colormanagement friendly routines
  • 98bbb882 - bake-cycles Cycles-Bake: Support for 'cancelling' the bake (Esc)
  • 02fc6ef1 - bake-cycles Cycles-Bake: Cycles changes for shader evaluation to support cancelling via progress cancel callback
Next Week

I would like to address bake-cycles bugs while they are reported. So far I've only got reports on BlenderArtists, and I'm waiting for the real reports to be migrated to our tracker, so I can take a look at them. Apart from that I will be working on multiview. I plan to bring it to git.blender.org, but I'm in the middle of a on-going work, so I may wait to push it in the end of the week, to get things working smoothly from day 1.

[edit] Week 32 (April 21th)

Info

I moved all the github commits to bake-cycles branch in git.blender.org. This include most of the entire history from January 1st on (the work before that was squashed even in github since it involved some files moving). Further commits were done in git.blender.org.

Main Commits
  • d41d1ceb - bake-cycles Cycles-Bake: Support for multiple high-poly objects selected at once
  • 42785c15 - bake-cycles Cycles-Bake: Tangent baking from multires
  • f1fe7537 - bake-cycles Cycles-Bake: bugfix for when no material is present
  • 68893054 - bake-cycles IMB buffer functions to take a mask as input
  • 993f316d - bake-cycles Cycles-Bake: "Clear" option fully supported

[edit] Week 31 (April 14th)

Info

Merge got delayed a bit since we decided to support yet new features: internal saving and multiple highpoly objects to active baking. Each one required a different refactoring in the operator code. I was to tackle the multiple-selection via changes in BVH but that would be too complicated. Instead Campbell suggested me to cast multiple rays, one for each BVH tree (one per highpoly object). This also made clear to me that *blockers* can be easily supported using the same system (basically we cast a ray to the blockers bvh tree as well and compare with the distance we got from the other BVH trees. Internal saving introduced another issue.

Main Commits

a1c99c03 - bake-cycles Cycles-Bake: internal saving and split image per material

[edit] Week 30 (April 7th)

Info

This week I started handling the remaining bits from bake-cycles code-review. The main one was to use DNA/rna for the operator options. Overall the review tasks are not hard since we are all in the same page it seems. There is still some small things I would like to address (multires > tangent map; ). Apart from that I use the rest of the week on game-dev bug fixing (my own features/previous assignments).

More specifically I fixed a bug in the view navigation where the camera would fall through the ground depending on the distance of the fall. It was a bit of a corner case, but it would happen whenever the falling speed was too big. Also, in the past weeks we got a few reports where the PSD file is not showing correctly in Blender. I finally looked at one of those reports deeply, and after some debugging, the problem (in this case at least) is on krita, not in OpenImageIO, not in Blender. More details in the related links.

Related Links
Next Week

I realized it won't be very doable to have bake-cycles unfinished (or unmerged) and get multiview rolling at the same time. At least for me to get full steam with multiview I will need to dedicate non-disputed time for it. That also means I would like to call bake-cycles done on its current stage before moving on. Giving the time of the Easters' holiday I propose us to wrap up bake-cycles by Wednesday and commit it to master. Then after that I will be fresh to give multiview the attention it deserves and to tackle loose ends from baking.

[edit] Week 29 (March 31st)

Info

This week in a nutshell: I started working one day in multiview, while waiting for the baking reviews. Nothing to show on that, I'm still re-familiarizing myself with the code, but I traced a basic work plan for future weeks. I then decided to start getting CUDA to build. Making long short I ended up having to upgrade to OSX 10.9, got Blender to finally build with CUDA (10.8.5 is broken for CUDA, it seems), and got bake-cycles to support CUDA. That said, baking itself will not support CUDA initially. I can't really debug since I got no NVidia. But at least rendering can benefit from CUDA, and bake-cycles can get in 'master' without bringing problems elsewhere.

Multiview Plans
  • Image Editor - it currently is not working, I left it half-broken when I left multiview work.
  • Full Screen - I would like to take this out of multiview and commit (send for review) on 'master'.
  • Basic Mode - get it to render left and right cameras (right now it only shows on viewport).
  • Pivot - option for the Basic Mode camera (left, center, right)
  • Everything else

[edit] Week 28 (March 24th)

Info

Code cleanup, documentation (wiki), and sent the code for a first round of review. Addressed mostly all of the review comments from Campbell (code cleanup and some small changes here and there) and waiting for Brecht review to do more changes. Fixed some bugs from the list (pre-divide direct/indirect passes by the color pass), and started with a fix for SSS (I'll need assistance on that, though). Meanwhile I merged the multiview code from master (last merge as in November 25, lots of conflicts to handle).

Code Review
Open Issues List
Subsurface Scaterring partial fix
Documentation
Next Week

Planning will depends on Brecht's availability for code review. As soon as I hear from him I can tackle remaining issues for baking, and perhaps we draft an integration plan (see whatelse we need to add before committing to master), it will depends on his comments. Apart from that I'll keep working on multiview. Now that merging is done I want to wrap up the image editor refactor, refresh my mind within the codebase, and draw a clear picture on the development planning. I will start by addressing the design changes suggested at the Blender Conference (in meeting with Brecht and Francesco Siddi).

[edit] Week 27 (March 17th)

Info

Main feature worked on: File-Types (PNG, JPG, ...). More User Interface work (here I ended up doing a lot of redundancy code compared to Blender C code - I had to implement a template for FileImageFormat, dynamic enums, ...), I'm looking forward to get some review on properties.py and ui.py - Cycles files). There are more small things I want to do before calling for review, but I'll do it tomorrow calling for review by the Sunday meeting.

Open Issues List
Next Week

I would like to get to low hanging fruits that show up from the review, and while waiting for big issues (and for Brecht to be back in activities) I would like to either start with anti-alias, or to start on multi-view. At least to start merging trunk in, so it gets updated, fix conflicts, so I can start working on it soon. To be discussed with Campbell since he may prefer if I prioritize wrapping baking while it's under the scrutiny of review.

[edit] Week 26 (March 10th)

Info

Most of the work was on Custom Cage and User Interface. User Interface is trickier than it sound since the functionality I'm building is an operator.

[edit] Week 25 (March 3rd)

Info

Week off (Carnival)

[edit] Week 24 (February 24th)

Info

Tangent space mode, general bug tracking.

Commits
  • d47d030 master: Fix T38819: Mark Seam misbehaves when accessed through spacebar search
  • b6bb6d1 master: Fix T38808: image opened with 'relative path', gets absolute path
General Bug Tracker Activity

https://developer.blender.org/p/dfelinto/

Next Week

More of the same. It was agreed that we would have 2 weeks of bug tracking for 2.70.

[edit] Week 23 (February 17th)

Info

I started this week committing the cage_extrusion and use_selected_to_active. I then worked on cage fixes, talked a bit more with Andy Davies, and poured a lot of time studying and trying to implement tangent space conversion. At the end of the week I moved on to implement WORLD and OBJECT normal spaces, as well as normal swizzle. This will help me to debug the TANGENT space mode.

I talked yesterday with Campbell, and we agreed on the road map you can see in the end of this week's report. The bottom-line is, Cycles baking is getting enough support from users to justify us implementing it even before changing Blender internal baking code. The original idea was to use Cycles Baking only as a start point to the baking refactor. However we are

I also did some bugtracker work, since this was the bug squash week. And once again, the help from Brecht (exchange over email) was invaluable.

New Features
  • WORLD and OBJECT normal space
  • normal swizzle (to pick the axis direction of each channel)
Road Map 
1. Finish up object to tangent space conversion
2. Custom cage
3. Other file formats
4. Anti-Alias * maybe
5. Code review and UI
6. Save to internal image data blocks * maybe
7. Make BI to integrate with all this
Links
  • Bake-Cycles branch [github]
  • Bake-Cycles-Dev branch [github]
Commits
  • 3d7e0aa bpy.ops.object.add_named() doesnt provide error when failed (related to T38689)
  • cbbc67a fix T38561: Fly mode vs. Walk Mode Navigation Keyboard Controls
  • d85d117 fix T38721 Vertex Group pop menu (CTRL+G) Set Active Group not updating Vertex Groups Panel
Next Week

Move on with the roadmap targets. The soon we can get to a review stage the better. It would be nice to merge this in 'master' in bcon1.

[edit] Week 22 (February 10th)

Info

I started converting my blog post into an updated status on Blender development blog. I also spent some time in a G+ Hangout with Andy Davies to learn about cages and the usual workflow (low-poly, high-poly, cage, extrusion, ...). The rest of the week was spent in the new features, and polishing here and there.

Also I took the time to improve the view navigation by adding info in the header. It should've been done with the original patch, but I was waiting to see if you were going to get an automatic header info generator (based on custom shortcuts).

New Features
  • Bleeding
  • Active to Selected
  • Parametric Cage
Links
  • Bake-Cycles branch [github]
  • Blender Developer post [blog]
Commits
  • 786ff5e Add header info for the Walk Navigation operator
  • 9388061 Add header info for the Fly Navigation operator

[edit] Week 21 (February 3rd)

Finished getting all light passes to work in Cycles (with help from Brecht). At the end of the week I wrote a blog post in my blog and placed a call for feedback on game-dev. This quickly caught BlenderNation attention and BlenderArtists.

Links
  • Bake-Cycles branch [github]
  • BlenderArtists thread[forum]
  • Dalai Felinto post [blog]

[edit] Week 20 (January 27th)

Info

Week off.

[edit] Week 19 (January 20th)

Info

This week I got the Cycles baking to work with my old code for some passes, refactored based on Brecht's review. Brecht decided on which passes we expect to bake in Cycles (see data and light list below). From them I implemented all Data passes already, and they are working fine. I'm currently stuck with debugging the Light passes. The code is supposed to be working but I'm getting black or really low values only. (it's all in kernel_displace.h if anyone wants to check).

Image of the week


Where to check the work
Progress made 
1. Refactored the Cycles part of the code to use the evaluation pipeline
2. Implemented all the Data passes
3. Fixed: Baking working for a scene with more than one object
4. Wrote the base code for the light passes (but AO, which will require something else), but not working as expected
Data Passes
  • Normal
  • UV
  • Diffuse/Glossy/Transmission/Subsurface/Emit Color
Light Passes
  • AO
  • Combined
  • Shadow
  • Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect
Next week

First thing is to finish the light passes. I hope Brecht has some time the week so he could help with that part and more important review the rest of the code, which should be nearly complete as far as Cycles goes. If Brecht is busy I can work on other parts of the baking (e.g., save in other image formats, save in internal images, AND internal baking using the new 'API'.

It would be nice if Campbell, Brecht and I (and other interested parties) could meet this week to decide what to tackle next. I started on the Cycles end of the equation because Campbell believed it would be the most problematic part, but with eventually out of the way we need to decide where to go from here.

Non-Related staged work, just committed
  • [D167] game engine: implement hitMaterial for collision and ray 67f1fd2

[edit] Week 18(January 13th)

Info

This week report includes the work of week 16 (3 day week), part of the week 17 (worked 13/20 hours, will pay the rest in the coming week), and this week (18th).

Where to check the work
Progress made

1. RE_populate_bake_pixels is working, generating a correct list with the uv barycentric coordinates of the faces for all the pixels to be baked.

Barycentric UV Bake

2. No more crashes when exiting Cycles

3. Image handling - I save the rendered data into an external image (decided to do that first to help with tests) 

bpy.ops.object.bake(type='COMBINED', width=512, height=512, is_save_external=True, filepath="/tmp/baked.jpg")

4. I wrapped BakePixel into rna properly, so in Cycles I can use BL::BakePixel instead of passing a pointer to the array and duplicating the struct in Cycles. That means, apart from the float array for the result, all the data going back and forth to the external engine should be implementable in other engines without hack-hardcoded data structs copied from Blender.

5. Got a partially working hack in Cycles to make a "Bake Camera". It works, and I can inspect the result in the EXR. But I dropped this attempt after Brecht's suggestion [details] - code [github]

6. Moved on to expand the kernel evaluation routine to take the content of BakePixel, process a shader and populate the result float array. This is where I am.

Next week

I plan to get the bake function in cycles to fully work. It should be working now, but I'm getting blank (gray actually) results returned from the shader_evaluate. Once I get some valid result I can move on to implement the needed routines for every one of the shaders. Since this sounds laborious I'm waiting to hear from Brecht on the current approach before doing all the needed monkey work. Regardless I want to at least get one or two of the shaders to work, to valid the pipeline.

Non-Related master commits

[edit] Week 17(January 6th)

Info

I took this week as off due to computer issues, I'm compensating this over the next weeks

[edit] Week 16(December 30th)

Info

This was a short week (3-day week) due to Christmas (last week's holiday) and New Years' Eve. I had some computer issues (watch out if you also have a 2011 Mac Book Pro) and had to leave the computer in the repair shop. To see the progress of the work refer to week #18, where I wrap up a decent week report.

[edit] Week 15(December 23rd)

Info

Holiday break, this week was a week off

[edit] Week 14(December 16th)

Info

I created the base code structure to connect the new bake operator with the external engine. The external engines interface now supports a bake function in the engines. Right now it passes the following arguments: 

RE_engine_bake(struct Render *re, struct Object *object, struct BakePixel pixel_array[], int num_pixels, int depth, int pass_type, float result[]);

This connects to the Cycles code, which can read the pixel_array buffer and populate result[]. The operator is called with: 

bpy.ops.object.bake(type='COMBINED')

So now I have the code pipeline set in place to implement void BlenderSession::bake for real in Cycles. See the Todo list below for the next tasks. Not much else to say but that it was a bit time consuming to get the rna/python/cycles glue together, but this part is mostly gone now (I still would like pass_type to be an int instead of a string, but that's for later).

I got some feedback from Brecht on the current design (though I'm going to run again by him), and things seems to be fine, with changes to be made later when we worry about optimizations (e.g., to call the external engine once to bake multiple passes at once).

Where to check the work
Next Week

I'll see how I'm going to do regarding the holidays. I would like to take a week break between Christmas and New Year's. As for the next work week: keep working on baking for cycles. The todo list is as follow:

Todo List 
1. Stop cycles from crashing on exit
2. Write the populate_bake_pixels () function - start of duplication of existent baking code.
3. void BlenderSession::bake() to actually render something (I will start with the derivate or background)
4. Everything else

After getting this concept working, it'll be time to decide where to move in terms of development. For example, should I do the image part? the Cycles part? the blender internal changes?

I'm inclined towards getting the image handling to work first, just so I can see in actual images the result of the output from Cycles. From there I can experiment with other passes types in Cycles (COMBINED, AO, ...) to get a good feeling of how well this will scale in Cycles.

That would mean: 

5. Image handling to save the result of Cycles
6. Other Cycles passes (COMBINED, AO, ...)
7. RE_internal_bake - to get at least one of the 'internal' passes working too (e.g., UV, Object ID, Material ID)
Pseudo-code

For now ignore the 'bakemap' references below this is just to help thinking how this will fit in the overall design and future changes for the current bake structure just consider that there is one bakemap made with the current render selected options and that we always save internally. 

for object in selected_objects:
  BakePixels *pixel_array[];
 
  # doing this at this point means a bakemap won't have a unique UVMap, which may be fine
  populate_bake_pixels(object, pixel_array);
 
  for bakemap in object.bakemaps:
    float *ret[]
 
    if bakemap.type in (A):
      extern_bake(object, pixel_array, len(bp), bakemap.type, ret);
    else:
      intern_bake(object, pixel_array, len(bp), bakemap.type, ret);
 
    if bakemap.save_external:
      write_image(bakemap.filepath, ret);
 
    elif bakemap.save_internal:
      bakemap.image(bakemap.image, ret);
 
    elif ... (vertex color?)

[edit] Week 13(December 9th)

Info

I started the week finishing the barebones for Bake-Maps. The UI has the basic mechanisms, we can add/remove new bake-maps, and most of the DNA and RNA done.

This was put on hold though, to favour the development of structural baking changes. Basically I'll work on the basic Cycles changes to allow it to bake, while using it to valid a baking API as proposed by Brecht van Lommel. Once the API is prove to be working, and even if Cycles baking is left as experimental code, we move the blender internal to use the new API. This way we can even push for the other baking changes (cage, anti-aliasing) before getting full Cycles baking done. This discussion happened over mail and irc between Brecht, Campbell and I. The plans are in the link below.

I started studying the Cycles code and have some small code, but nothing to share yet. Apart from that I wrote a bash script to help me build blender and install only Cycles since I'll be needing that a lot. It's the Blender-Maker below.

  • Baking Priority Plans [wiki]
  • Blender Maker [github]
Bake Maps Snapshot
Bake Maps
Commits
  • 4b127df - fix: Fly Navigation centered in viewport, not in camera view
Staged Commits
  • (D102) - fix for T37806 - Using Fly Navigation with camera with parent
  • (D101) - Add optional 'frame' argument to scene.timeline_markers.new(name)
Next Week

Keep working on baking for cycles.

[edit] Week 12(December 2nd)

Info

This week I finished the View Navigation implementation, created the documentation for it and pushed it to master (big kudos to Campbell Barton for the help through this feature). After that I started with the Bake Map work. I'm still working in the barebones, but I have the DNA, rna, UI getting into shape.

Where to check the work
Commits
  • ab49437 - View Navigation: Walk and Fly modes
Wiki Documentation
Next Week

Keep working on bake maps.

[edit] Week 11(November 25th)

Info

I spent Monday trying to figure out an issue with triangulation, which was later fixed by Campbell. The rest of the week was working on the walk navigation issues raised during code review.

The system is trunk ready for OSX (and Windows?) but for Linux I'm looking at an alternative to the cursor wrap issue (as pointed out by Campbell).

Code Snapshot
Branch Commits
  • Rename file and variables from fps to walk
  • Unifying walk and fly modes into VIEW3D_OT_navigate
  • Change up/down to Q/E keys
  • Expose gravity in the ui
  • Acceleration/deacceleration
  • New shortcuts (MMB, ...)
  • Remove X/Z rolling
  • Teleport distance clamp to positive
  • Huge cleanup
  • Fix aim draw not centered
  • Q/E no longer affects camera_height (they now only work on FREE)
  • Fix for when camera gets stuck
  • Using camera control API
  • Bug, not using EARTH_GRAVITY
  • Scale the scene movements relative to the scene size
  • Fix for sidewalking
  • Offset distance for teleport
  • Remove temporary keys
  • Reverse Mouse option
Trunk Commits
Next Week

As soon as we sort out the Linux issue, the code will be trunk ready in my opinion. After that I was considering to start with the baking proposal. Initially the UI part of it, so we can merge it in parts.

[edit] Week 10 (November 18th)

Info

This week got us quite far with the navigation system upgrade. The current code is near feature complete, and I finished up the week talking with Campbell on design changes and review of the functionalities.

Next Week

I'll go over the tasks below, do some bug hunting, and hopefully get things merged. I don't know if the wiki has a place for this feature, but if not I can write a code.blender.org post on that, if Ton find relevant.

Code Review Tasks
  • The Navigation operator will unify both the old (Fly) and the new mode (Walk/Free). In User Preferences the user wil lbe able to pick which mode to use by default (it will also be a parameter in the operator, so users can bind different keys for both modes).
  • The settings will be stored as:

bpy.context.user_preferences.inputs.navigation_mode [WALK/FLY]

bpy.context.user_preferences.inputs.walk_navigation.*

bpy.context.user_preferences.inputs.fly_navigation.* (placeholder)

  • The walk mode will have a gravity option, off by default, so the default behaviour will be the Free navigation. All the new code will have to suffer batch rename from fps to walk (the view3d_fps.c included).
  • Not to be tackled by this patch, but we need a nice API to draw in the header while running the operator (to inform the user about the shortcuts).
  • To change Fly Mode Up/Down shortcuts to Q/E (to mimic the new Walk mode).
  • There will be no Walk mode where you don't fall through the floor. It's easy to implement (and we had it at some point), but I think it's not necessary. Let's see what users think ;)
  • Space and MMB will be Teleport
  • V for Jump (vertical)
  • To implement speed modifiers, +/- and mouse wheel. They can be static variables or operator settings, so they are kept while Blender is on.
  • Speed could/should be relative to unit_settings.scale_length. The viewport grid is doing something similar.
  • Z and X roll correction will be left out for now.
  • NDoF will not be supported for now (neither Campbell or I have a working Space Navigator).
  • Teleport should try to land in an offset to the hit point (right now it's 80% of the total distance).

[edit] Week 9 (November 11th)

Info

I spent the week working in the FPS Navigation System. Today was actually a national holiday (Republic day), I wasn't supposed to work, but I spend some time migrating my repos to the new git.

The FPS development can now be found here:

Features implemented
  • Terrain mode
  • Fly mode
  • Run modifier
  • Cross cursor
  • Teleport
  • User Preferences

New Youtube Videos:

Future plans/next week

I believe we have enough elements to wrap the navigation code this week. Campbell is busy with the git migration, so, so far our discussions have being mostly on implementation and feature scope. Not much nitty-gritties of implementation.

I would like to get the 'mouse-look' more like people seem to expect (spoiled fps players ;). Mainly I need to compensate the jigger-ish effect I get when I use no damping. And it may make sense to remove the Walk mode and replace it with the Terrain mode (so we either walk in a terrain, or fly around). I also need to implement a gravity system (I have in my mind how to do it already, need to code though). And teleporting is working, but it could use some improvements, mainly to act differently if the hit surface points upwards or forwards. I hope we can aim at committing this at the end of the next week.

[edit] Week 8 (November 4th)

Info

The week really started on Wednesday for me, due to BlenderPRO. The conference was interesting, my talk on "Game Development with Blender" (talking about BGE, my book, and our game-non-bge development) was well received. I should have a youtube link of it soon. I also attended a workshop on "game industry", about compliance tests, game design (the document, not the art), and other related topics by [Gerson Soares], Executive Manager of [AbraGames] - (Association of Brazilian Digital Game Developers).

Now for the development. FPS navigation is working. It can be improved, and definitively cleaned up. But it's working, which is quite cool. Implemented so far:

  • Ctrl+Shift+F : enable FPS navigation mode
  • WASD (or arrows): forward/backward/left/right navigation
  • RF: up and down
  • Mouse move: look around

This is built on top of the fly navigation system. (I started that with a big ctrl+c, ctrl+v).

Zeno Damping System

The mouse look damping system is based on the [Zeno's Paradox]. Basically if you move your mouse to 0.4 away from the center, Blender will rotate the camera only a fraction of this value (e.g., 20% * 0.4 = 0.08), and then re-place the cursor to the remaining part of the offset (e.g., 80% * 0.4 = 0.32). Next frame then Blender will repeat this until the offset is close enough to 0.0 that it stops moving. That means that if you quickly move your mouse, Blender will make a smooth rotation of the camera.

The re-centering of the mouse cursor prevents the user from having the mouse away from the viewport during the navigation. It's also a common trick used by the BGE navigation scripts (mine included).

Next Week

I want to finish the fps navigation system. It would be nice to add a 'walking in the terrain' mode, where I would cast a ray and try to go up and down following the terrain. Apart from that I want to hear from Campbell his first thoughts on the implementation and any consideration.

Apart from that, Campbell also liked the [Texture Baking Maps] design, so regardless of the criticism in the bf-game-dev list, I would like to start implementing it.

[edit] Week 6 & 7 (October 21st and 28th)

Info

Last week (6th) was formally a non-paid/work week as agreed with Ton. So this is a double report covering mainly the Blender Conference and small bits of work that I managed to go over during this week (7th).

The conference was quite satisfying for the game-dev work, and general Blender work.

I met Andy Davies (metalliandy) and we talked specifically about the triangulate modifier changes, and how that fits in others pipeline (see email/proposal below). He also went over his Normal Baking presentation (his workshop was at the same time of my talk, so I couldn't watch it). For the records: [youtube] - [files].

Also the presentation from Sebastian Ullrich / [Sense Graphics] is relevant to our work. See this part regarding the x3d/h3d exporter and the changes they made [youtube~16m17s]. Basically they are looking for support to get the changes they made back into trunk. I don't think we can take on implementing all i/o formats out there, but I can see we reviewing/advising external groups like his, to get their work in trunk. I'll keep in touch with them, but meanwhile one thing that can already be done is to review this patch: #29335 - Python api for exporting tangent space normals through script which is required by their exporter.

On top of that I met with other developers, and drafted a few proposals (see below).

Finally, deviating a bit from game-dev, my presentation on multi-view was quite well received [youtube] - [pdf] . I'm investigating how to best wrap up this project, since there seems to have a lot of interest on it. We may arrange to have someone else taking on my game-dev duties while I put time on multiview (paid/unpaid/external funded, we will see). Nothing to be decided before late December/January though. Nevertheless I had a final design meeting with Francesco and Brecht and we addressed all the missing bits. With that I will keep the branch update with blender's trunk and the issue list well crafted. There are some developers that are interested in helping and may be able to wrap part of the work. For that I will be around, but shouldn't be dedicating much time for the multiview work.

Next Week

FPS Navigation - I started FPS dev this week, but it's too early to share anything. I'm heading to BlenderPRO 3-5/November (Brazilian Blender Conference) tomorrow, and will return early on the 6th. I'm giving a talk on "Game Development with Blender" and a workshop on "Python addons for Blender". I'm hoping to find time to sit and code while there as well. This is the last conference of the year, so things should go back to normal after that ;)

Proposals
  • Triangulation Modifier changes, and feedback [bf-gamedev]
  • Texture Baking Maps - Proposal [bf-gamedev]
  • Multiview Updates - [github]
Bug fix
Stage Commits
  • Triangulate Modifier: using different ngon and quad methods. r60983
  • Triangulate Modifier wiki doc [wiki]
Non-Related
  • Python ui: increase interface float precision limit from 6 to 7. r61021
  • Missing bit from last float precision update (patch by 'unknow' via irc). r61054

[edit] Week 5 (October 14th)

The week was spent mostly on making the triangulate modifier error-proof. It still failed (T37145) but the system is working pretty nice and I got all (but cage preview) planned features finished.

Next week I'll be offline for quite some time. But I'll try to put some work hours on the FPS navigation system. I've been working around the clock to compensate a bit because I know the next two-ish weeks I'm going to have a weird agenda. Part of this is due to Blender Conferences (Blender Conference 25-27, and BlenderPro 2-5). I'll log the worked hours and if I can't put a reasonable amount we find an arrangement.

As for tasks, the next in line is FPS navigation. After that it would be nice to get together again and discuss the next todos. I'm counting on meeting Brecht and Bastien on Monday (and Tuesday, but Brecht only) on the Blender Institute to discuss possible works. I think viewport and baking make for good topics to be discussed tete-a-tete.

Bugs I'm working on
  • T37145 "Triangulate Face" crash in specific scene.
Next Week

FPS navigation

Staged work
  • Rotate Quads (Ctrl+F > Rotate Quads) [github]
  • Triangulate Modifier: using different ngons and quads methods [github]
  • Triangulate Modifier wiki doc [wiki]
Feature
  • r60805 Triangulate modifier - beauty option is back
  • r60794 Beautify: passing edge/face flags as arguments
  • r60793 Split operators/bmo_beautify.c into tools/bmesh_beautify.c
Bug fix
  • fix T37080 The file which I stored in PSD file format in Blender cannot open by Photoshop. r60776
  • fix T37058 2.69 RC1: Symmetrize directions are all reverse. r60724
  • fix T37046 Dissolve edges and vertices problem with triangulate. r60722
  • fix T37034 Triangulate modifier asserts with GHASH_FLAG_ALLOW_DUPES. r60719
  • fix T37059 OSX Debug - assert when using external screen with MacBookPro r60716
Commits
  • Including missing modifiers in the file rna_wiki_reference.py. r4810
  • Renaming "Beautify Fill" to "Beautify Faces". r60782
  • Cmake/ openimageio - partially reverting (r60692). r60718

[edit] Week 4 (October 7th)

Info

I started the week finishing the scanfill implementation for the triangulate modifier with help from Campbell. Next, once we went 'bcon1', I merged this and the PSD Support in trunk. My next task was to exposing the beautify tool, which was fine, and then integrate it with the triangulate modifier, which wasn't so fine. My current take is apparently correct, but it's segfaulting. In the meantime some reports show up, regarding the triangulate changes which I think may explain why my beautify patch is not working, since it assumes the triangulate modifier is working fine.

I had a bit of a drawback: To better debug those asserts and memories errors I went on to build gcc4.8. Blender failed building though (I'm having Jens Verwiebe helping me with that), and I messed up my building environment. That means I'm currently building only with XCode. Once I get that sorted out I will have scons building again here (I suspect I broke scons building)

Bugs I'm working on
  • T37034 Triangulate modifier asserts with GHASH_FLAG_ALLOW_DUPES
  • T37046 Dissolve edges and vertices problem with triangulate
Next Week 
1. Finish pending development from last week (beautify + trimodifier bugs)
2. Finish pending tasks from last week (fixed and fixed alternate methods, preview mode support and small operator to rotate vertices index for quads.
3. FPS navigation (hopefully starting around Wednesday).
Work in progress
  • beautify operator to sue with scanfill [github]
Work staged
  • split operators/bmo_beautify.c into tools/bmesh_beautify.c [github]
Commits
  • Triangulate Modifier changes - using scanfill r60618
  • Photoshop PSD support r60621
  • fix building when WITH_PSD is OFF, stub is not needed afterall r60622
  • fix for building with OPENJPEG after PSD commit, reported via email, patch by PerfectionCat r60623
  • fix T37011 "Save Copy" option misfunction r60644
  • ocio build fix for Windows - report by email and patch by Benoit Bolsee r60664
  • adding WITH_IMAGE_OPENIMAGEIO and removing the PSD build option r60686
  • scons file for OIIO (needed for psd) based on patch by Shinsuke Irie r60687
  • adding url for openimageio project in CMake file (OpenEXR and OpenJpeg do the same) r60688

Fixed: 1, Patches 0, Closed: 1.

[edit] Week 3 (September 30th)

Info

I started this week finishing the upstream patch for oiio/psd. Brecht finished his review on my work and I pulled it to the main oiio repo. The patch was approved by Larry Gritz and should be merged soon. [link]

Since the last week was spent most of the time with feature coding (psd) I've originally decided to put some time in the tracker. I regret the decision a bit, I found it quite disruptive to do tracking and feature work side-by-side. As for the tracker I put time on confirming some bugs, bisecting one (those I like to list because not only they help a lot, but they can be time consuming) and the usual asking for more information from users.

Finally I started the triangulate modifier changes. The first part was ok, basically understanding how modifiers work (my first time in //source/blender/modifiers/) and doing the triad DNA/RNA/UI - [patch]. Campbell reviewed the patch positively, but asked to keep it on hold and instead to start by replacing the current inline tesselation with scanfill.

I must say it was really hard (and time consuming) to make sense of scanfill and bmesh on my own at first. Even though we have a nice dev doc for bmesh, our code has not a lot of documentation and I couldn't find enough examples to extrapolate the internals (and the amount of macros don't help either). That said, I managed to get scanfill working for quads and some ngons (after Campbell patiently walked me through some points). After discussing with Campbell we decided it will be easier (and faster) to change the approach (no longer split edges, but create brand new faces instead) but that wasn't finished in time. [link].

Note:

By no means I mean to rant or to create excuses. it was not a week as productive as I expected, and that's fine, we all have those. The thing that was getting on me is that it's really frustrating to not progress in some tasks that are supposed to be basics. I could have bothered other coders even more than I did. But I learn way more after some head-banging on my own. Either way, I can't even imagine how I could tackle some more heavy mesh features (baking?) without getting through this learning process. I just wish it was less painful ;) Big thank you note for Campbell for repeatedly walking me through my BMesh/scanfill issues.

Links:
  • OpenImage upstream pull request: [github]
  • Triangulate Modifier New Methods Patch (ui/rna/dna): [github].
  • Triangulate Modifier ScanFill Patch: [github].
Next Week 
1. Finish scanfill using new triangles
2. Add new methods for quads/ngons (fixed, fixed alternate, ...) 
3. Get it to preview in edit mode
4. Add small operator to rotate vertices index for quads (to use with fixed/fixed alternate)
5. Start on FPS navigation and see how far we can get.
Reported
  • T32346 Node animation, removing nodes keeps FCurves. r60495
Non-Reported
  • Changing shortcut to toggle Properties in text editor (ctrl+t) r60444
Helped (git bisect)
  • T36850 Material Node Editor Crash Always. (fixed by Lukas)

Fixed: 1, Patches 0, Closed: 0.

[edit] Week 2 (September 23th)

This week I dedicated most of my time in implementing PSD support. The base work was easy and was reviewed early by Brecht.

I produced this demo video which was well received, and gathered positive responses on Twitter.

The problem (and what drained most of my time) is that OpenImageIO support for Photoshop PSD is incomplete.

I assumed the problem was that alpha was not associated in the file. Thus by Brecht's suggestion I mimic what the solution he implemented in oiio/tiff and came up with this patch.

However, to our surprise, alpha is not stored in the file in either associated or unassociated way (aka premul and straight/key alpha). And due to the lack of documentation after testing extensively I came up with this test grid:

Photoshop Alpha Grid

And Brecht came up with those formulas (which I confirmed here)

  • CompRGB = alpha * RGB + (1-alpha) * Background
  • RGB = (CompRGB - (1 - alpha) * Background) / alpha


Links:


Next Week

I'm going to go back at tracker work, tackle the Triangulate Modifier changes as proposed in my ideas list. If I'm done with the modifier I will start on the FPS navigation. It will depends on how much time the tracker demands, since that's still our top priority.


Notes
  • Since we are close to 2.69 release I will keep the features' development in github branches. This proved handy for review and things will be ready for merge when trunk is in bcon1 again.
  • Last Friday I was invited to the [gnugraf.org/2013| VI GNUGraf] to participate in a round table on 'Computer Graphics and Oopen Source'.
  • Also on Saturday I gave a speech on 'BGE and Game Development with Blender', talking about my work, the BGE and the future of game dev'ing with Blender (Teamworkshop, ...).
Non-Reported
  • rna: implementing function to remove keymap from keyconfig. r60395
  • CMake: BOOST is a dependency of OpenImageIO. r60357 (I needed that for PSD)
  • typos on error messages in CMake r60332
Helped (git bisect)
  • T36841 UV-Maps cannot be renamed in EditMode. (fixed by Bastien)
Closed
  • T6813 Segfault using groups in texture nodes.

Fixed: 3, Patches 0, Closed: 1.

[edit] Week 1 (September 16th)

Info

I wasn't expecting to 'hit the ground running', however the first week turned out to quite productive. I started tackling unassigned bugs from the tracker, from diverse areas (without necessarily focusing on game). The general bugfixing went smooth with the exception of T36786/r60288 that took me hours to write a patch that I could now write in half an hour. It taught me about our custom data layer system, so it was worthy. (apart from that even other coders I ran into were suggesting to use index ordering, which turned out not to be necessary).

Now and then I still hope I can tackle a bug out of my 'comfort zone' to build up more redundancy in our development team.

Apart from that, a few hours were dedicated to formulate and discuss the ideas presented here: http://wiki.blender.org/index.php/User:Dfelinto/Ideas

I talked with Campbell, Brecht and Montagne on specific points in the list, and we seem to be on the same page. It's not easy at this point to estimate how much time some of those tasks will take. But with the approved design I can work on it while fixing bugs on the side and keep moving forward.

Next Week

I'm planning to do more bug fixing and get my hands on either the PSD Support or the Triangulate Modifier. (I already got started with the PSD one, but I still need to assess how long it will take, and if it's worth pursuing this week.

fixes (reported)
  • fix/workaround: T36501 Blenderplayer can not change video resolution in Mac OSX. r60165
  • fix: T36736 You can still transform objects while navigating view (maya preset) r60168
  • fix: T36757 Vertex coloring in preview window meshes default to black, makes preview useless. r60206
  • fix: T34663 Cannot rotate view while using Knife tool with Maya preset. r60207
  • fix: T36641 Maya keymap: Border select doesn't add to selection. r60225
  • fix: T36724 Ctrl+F in text editor opens Toolbar, but no longer closes it. r60270.
  • fix: T36786 Customdata layers are not merging taken the names into consideration. r60288
fixes (unreported)
  • add support for trackpad navigation while in knife operator. r60204.
  • Text Editor: 'Find' (in the Edit menu) was pointing to the wrong operator. r60271.
extra

Fixed: 9, Patches 0, Closed: 0.

Retrieved from "https://wiki.blender.org/index.php/User:Dfelinto/Foundation16"