Here’s the original shape-key enhancements proposal from the mailing list. May be outdated:
https://dl.dropboxusercontent.com/u/91422001/revzin_gsoc_proposal.pdf
And here’s the mailing list discussion:
http://lists.blender.org/pipermail/bf-committers/2014-March/042986.html
As far as I know there’s no ability to see the GSoC rejected proposals beyond what you can find on the mailing list and wiki.
http://lists.blender.org/pipermail/bf-committers/2014-April/043351.html
For those who wonder - why “only” seven projects: we actually selected 9 very good proposals, but two students also had a proposal accepted at another organization. In both cases we connected about this, and it was clear that the other (smaller) orgs would benefit better from the student’s work then we would.
None of these organizations (nor we) had backup students to fill in. Overall, the quantity and quality of proposals this year was lower, but we also selected a bit more strict than last year (15 total).
If we are lucky, in the year 2021, we might actually see these added into trunk. Its all good to get excited about gsoc projects, but lets save it till when its actually IN blender, otherwise we repeat the same temporary hype threads as last time.
2 cents
Great projects ! High hopes for Cycles optimisations and maybe extension of the GPU supported features … Good luck !
That’s awesome. I know it’s not related to anything in this post, but I just posted the video of him chanting “Nerds” the other day. Great minds think alike I guess. :evilgrin:
Viewport FX III, I hope we’ll see some improvements in viewport before Viewport FX XX.
There’s already a number of projects from 2013 in Trunk right now (like the Laplacian Deform and DingTo’s work on Cycles), the deformation blur project also had some code extracted from it for the official implementation now in Cycles, Psy-Fi’s 2013 paint branch code is also about to go into review for final inclusion so I think you might be overly pessimistic about applying a broad brush to every project on the list.
However, it is true that some will never officially get into Blender because the code quality is not good enough or the student leaves the development scene and expects to place the burden of maintenance on the core team.
Maybe they are trying to make sure that the participants will have their code end up in blender
even with this they wont be sure of that, most of the dropping is because of a sudden issue.
@richard: i already read that in the mailing list, but thank you.
i think the year 2012 was the best, also they all got integrated fast, i was hoping for the lipsync proposal to get in, i think i should resume work on my lipsync importer addon then.
Maybe not the good thread to talk about that, but, I think it will be great to have this kind of auto remesh.
If we have a 3d scan or a dyntopo, we could select some part, make a polygroup and then put the autoremesh button to autoremesh the mesh.
That will give edgeloops between polygroup and then good result in smooth.
To anyone not familiar with Google Summer of Code, there actually have been many GSOC projects that have contributed greatly to Blender. Contrary to what someone else thought, many were actually included into trunk in a reasonable time period or are well on their way to be included. This isn’t a complete list, but a few to mention that are kind of awesome.
So my 2 cents, we should get excited to show the students the community appreciates their contributions. It seems to have worked out pretty good in the past! Best of luck to all the students this year!
this is the autoremesh I am dreaming of:
http://www.inf.ethz.ch/personal/dpanozzo/videos/sketch-based-generation-and-editing-of-quad-meshes.mp4
it is good because it gives you SOME control over the flow!
It’s a must on characters
Ah, so it is the earliest-mentioned paper.
Interactive session with user to define features points.
Hmz, well, buckle up you guys who really want to be sure to define the parts that only need to be simple loops 
That remeshing proposal isn’t looking so good. Not enough control. In fact it doesn’t seem like you get any control over the edge flow, not even zRemesher/3dCoat style. It looks like at best you can define… I’m not even sure what the red points represent.
Has this proposal been discussed with any of the modelling/sculpting users? Has someone checked how the paper’s authors’ implementation behaves on real high-density models, other than the trivial ones in the paper?
Now, it’s perfectly possible I’m mistaken and this will be a great addition to Blender, but my gut tells me it won’t work so well.
I was under the impression that it was just a simple remesher, much like zbrush’s dynamesh. Or a better version of blenders current remesh modifier
not some auto retopo tool, like zremesher
I think because its called zREMSHER in zbrush people are confused here.
perhaps i’m wrong, I haven’t read the proposal in full. so apologies in advance.
For me the remesher should be cutting edge technology.
An older approch it doesn’t help much.
Seeing these red points, I am thinking that it might be armature joints.
Skining and Remeshing at once. 
IMHO, images are here to show the idea of gradients (point 1,2,3)
There is no picture for point 4 and 5. Maybe another user interactive session can be set at point 5.
Interactive session with user to define features points.Construct the harmonic scalar field.Based on harmonic scalar field compute a gradient field.Define two orthogonal vector fields using the gradient field.Define a net of polygons over the original surfaces with the use of integral lines defined by the orthogonal vector fields.- Generate a new mesh.
About the remeshing algorithm. Its nice and simple (for the user) however this may be a semi deal-breaker for some, a paragraph from the original paper (pg.19):
As mentioned before, the resulting mesh is generally non-conforming. There will be so-called T-junctions where flow lines were terminated by the local spacing control. This is quite apparent in Figure 7c. For those applications in which non-conforming meshes are undesirable, we perform an optional post- process to remove all T-junctions, adopting the same template-based strategy as Alliez et al. [2003a]. We also triangulate polygons with more than 4 sides using a simple ear-cutting algorithm. After post-processing, the mesh consists solely of quadrilaterals and triangles, and is strictly conforming. Figure 7 shows an example of a mesh both (c) before and (d) after post-processing.
Basically it doesn’t handle poles at all, leaves them hanging as T-junctions and merges to triangles as post process.
Uhm, guys, if you read the gsoc proposal more carefully, you’ll see that the guy is fully intending on having a good talk with end-users first before implementing anything.
Hence me saying ‘you should get ready to give feedback’. Make a nice bullet-pointed list, etc.
Edit: The red and blue points are extremeties. The idea is that a sort of surface-flow gradient is drawn from one extremity to the other, and based on that the edgeloops are made.
But seriously though, if you need better edge-loop control, or better pole handling, get ready to give that feedback.
