[Bf-committers] GSoC Proposal

[Grigory Revzin]

Hi all.

It was suggested on the dev wiki that GSoC proposals are to be posted
on the mailing list, so I'm doing this now. I would be happy to hear
feedback from developers if possible.

The proposal is about enhancing shape key editing workflow in Blender.

Draft: https://dl.dropboxusercontent.com/u/91422001/revzin_gsoc_proposal.pdf


Thanks.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC Proposal

[Rabindranath Andujar]

Hi there!
I'm sorry I presented my proposal a bit tightly, so I was unable to ask for
feedback.
I just knew last wednesday about GSoC, so I had to prepare everything a bit
on the rush...

However, here you are:

http://wiki.blender.org/index.php/User:Ndujar

I hope you find it interesting.

Rabindranath Andujar

P.D:

I have had a little accidental intercourse with the wiki proposal template.
I hope it's all fixed up.
As a newcomer, I though editing the template was the thing to do in order to
get registered.
As soon as I have noticed my bad behaviour I have fixed it.
It's been very embarrasing.
Sorry if it caused any inconvenience.
Thanks for your comprehension.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal

[shuvro sarker]

This is the link of my GSoC proposal. There are two links in the following
page -

http://wiki.blender.org/index.php/User:Shuvro

Please review the proposals and give me any kind of advice regarding the
improvement, edit and
your thoughts about the ideas.

Stay fine. Thanks.

Shuvro
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal

[Sergey Kurdakov]

Hi Shuvro,

I have one thought to share on subject of motion capture

 that while there are a lot of samples now when  kinect allows to get motion
capture data
ex http://www.brekel.com/
- one kinect is very hard to make to produce good animation data.

so, while there are quite a bit examples to use Kinect to make motion
capture - it exibits weakness here and there - captures mostly standing
persons, feet sleeps, etc.

There is another approach though.
To use two kinects.

You might look at Oliver Kreylos

http://idav.ucdavis.edu/~okreylos/ResDev/Kinect/ page and also
http://www.cs.ubc.ca/labs/imager/tr/2009/eltopo/eltopo.html software - then,
I expect, it is possible to reconstruct skeleton at each time frame.


To estimate mesh from Oliver Kreylos  data you might use recently
implemented double contouring  algorithm
see http://vimeo.com/21096739 ( diff here http://www.pasteall.org/20117/diff
 )


this way - it would be possible to capture professional quality motion
capture data and not something with sleeping feet.

as a side note you may look at paper
http://openmesh.org/uploads/media/Hornung_TR10.pdf
while not directly related - it might be of some help in implementing above
mentioned approach.


Regards
Sergey

On Sun, Mar 27, 2011 at 11:01 AM, shuvro sarker  wrote:
>
> This is the link of my GSoC proposal. There are two links in the following
> page -
>
> http://wiki.blender.org/index.php/User:Shuvro
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal

[Sergey Kurdakov]

Hi Shuvro,

I believe, that there are could actually many directions in implementing
what I mentioned in previous message.

1)st auto calibrate kinect(s) see available software
http://graphics.cs.msu.ru/en/science/research/calibration/cpp
2)a reconstruct scene from kinect using  http://vimeo.com/21096739 ( diff
here http://www.pasteall.org/20117/diff )
using either Kreilos approach or maybe
http://www.ros.org/wiki/openni/Contests/ROS%203D/RGBD-6D-SLAM approach
2) b fit
generic figures to captured data ( generic figures could be taken from
MakeHuman, I think )
3) estimate motion. see additionally link
http://www.ros.org/wiki/openni/Contests/ROS%203D/Skeleton%20Tracker%20Teleoperation%20Package%20for%20Mobile%20Robot

so
pretty much to do.

but unlike your proposal - it does not rely on patented pending approach
implemented in Nite based code (Extraction of skeletons from 3D maps United
States Patent Application 20110052006 ) and potentially provides much more
reliable
motion data capture.

as for Blender and Nite you may see here
http://www.youtube.com/watch?v=UxIcwuo5Rts it is already tested with
http://www.brekel.com/  tool - which is basically a wrapper around Nite.

I just add some info to think on if the way you describe is really worth
pursuite

Regards
Sergey
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal

[Sergey Kurdakov]

Hi Shuvro

see also
http://nicolas.burrus.name/index.php/Research/KinectRgbDemoV5?from=Research.KinectRgbDemoV4

Regards
Sergey
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal

[Sergey Kurdakov]

Hi Suvro,


I also suggest you look at following links


http://blenderartists.org/forum/showthread.php?207281-Using-OSC-in-Blender-2.5-Game-Engine-(with-Kinect-captured-data)
here a script to import animation data is developed ( based on Nite etc )

and papers to estimate skeleton based on my suggestions ( two Kinects )

http://www.andreagiachetti.it/ActiveSkel/lcg_mirage2009.pdf
http://www.win.tue.nl/~alext/ALEX/PAPERS/VisSym02/dskel.pdf
http://alexandria.tue.nl/extra1/wskrap/publichtml/200638.pdf
http://iwi.eldoc.ub.rug.nl/FILES/root/2008/LNCSReniers/2008LNCSReniers.pdf

Regards
Sergey
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal

[Yousef Hurfoush]

hi all

nice feature but wouldn't it be better to go for an anonymous device type for 
capturing rather than kinect. 
basically for low salary countries like mine paying 650$ to get a double kinect 
is not much of a choice :)

here is sample of a capture software using  an anonymous camera device, they 
use PS3 camera as recommended device and you can use any good quality camera, 
i tried it with two cheap cameras (10$ for each) @ home and it worked very good 
and the software is able to handle about 6 cameras for accuracy.

thanks
Yousef Harfoush

i'm sending this again after subscription 
  
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal

[Sergey Kurdakov]

Hi Yousef

>it be better to go for an anonymous device type for capturing rather than
kinect.

you might  consider to look and try

http://code.google.com/p/openmocap
http://www.motioncapturedata.com/2009/06/cheap-motion-capture-with-free-software.html

it might be a good addition to Blender too if it works well

and maybe this path will be selected as GSoC

Regards
Sergey
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal

[Павел Краснов]

Hello, my name is Pavel Krasnov and I'm looking forward to join you on
Summer of Code. I want to work on “Fast Import/Export for selected
format” project. I would like to see your feedback. What do you want
to see from students? Which skills? How you will evaluate are student
appropriate or not? My draft proposal is here
https://docs.google.com/document/d/1dHevLvduCSjL928EXXWWHSxix-Ww1JCqTkFo6Tkxon4/edit?usp=sharing
.

Thanks.

-- 
With best regards, Pavel Krasnov.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSOC Proposal

[ANISHA JAIN via Bf-committers]

Hey,

I am Anisha Jain. I am studying in the pre-final year in CSE, at National
Institute of Technology, Warangal.
I saw that Blender is listed as one of the organizations at GSOC.
I have recently started working on Blender and am learning modelling on it.
And thus was very excited to see Blender listed at GSOC.
But when I thought of doing research to find out which project I would like
to work on I got confused among the sea of things that were present on the
web pages.

I am specifying my skill set below and I would be grateful if you could
guide me to project that I can do.
C, C++, Python, Java, C#, JS, React, PHP, HTML, CSS, ML, Deeplearning
PS: I  am ready to learn any new skill that might be required.
I have worked at Microsoft for a summer internship
Hoping to hear from you soon

Thanks and Regards
Anisha
[image: cloudHQ]

Powered
by
cloudHQ

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal

[Howard Trickey]

I wish all proposals had this amount of thought and detail in them. Nice
job on the writeup!

I am not well--versed in this area of Blender, but to put in my outsider
opinion, I like this proposal.



On Thu, Mar 6, 2014 at 12:55 PM, Grigory Revzin  wrote:

> Hi all.
>
> It was suggested on the dev wiki that GSoC proposals are to be posted
> on the mailing list, so I'm doing this now. I would be happy to hear
> feedback from developers if possible.
>
> The proposal is about enhancing shape key editing workflow in Blender.
>
> Draft:
> https://dl.dropboxusercontent.com/u/91422001/revzin_gsoc_proposal.pdf
>
>
> Thanks.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal

[Grigory Revzin]

Thanks a lot, I'm now more confident in submitting this stuff :)


On Thu, Mar 6, 2014 at 10:17 PM, Howard Trickey wrote:

> I wish all proposals had this amount of thought and detail in them. Nice
> job on the writeup!
>
> I am not well--versed in this area of Blender, but to put in my outsider
> opinion, I like this proposal.
>
>
>
> On Thu, Mar 6, 2014 at 12:55 PM, Grigory Revzin 
> wrote:
>
> > Hi all.
> >
> > It was suggested on the dev wiki that GSoC proposals are to be posted
> > on the mailing list, so I'm doing this now. I would be happy to hear
> > feedback from developers if possible.
> >
> > The proposal is about enhancing shape key editing workflow in Blender.
> >
> > Draft:
> > https://dl.dropboxusercontent.com/u/91422001/revzin_gsoc_proposal.pdf
> >
> >
> > Thanks.
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
Г. Г. Ревзин
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC Proposal: NURBS

[Jonathan deWerd]

Feedback is welcome, but I’m really looking for a mentor :)

https://dl.dropboxusercontent.com/u/8406827/NURBS_GSoC.pdf

I emailed Laurynas Duburas (the 2005 NURBS GSoC student) and Emmanuel Stone 
(the 2009 NURBS push guy) on Friday. Neither has responded yet :(
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC proposal

[Davis Sorenson]

Hi,
I'm not a developer or someone who knows about implementing such a project,
but I happened to see a paper from Microsoft about their body tracking
algorithm, which I would assume is the one actually used in the xbox. There
was also a video about it, that I haven't watched.
http://research.microsoft.com/pubs/145347/BodyPartRecognition.pdf
http://www.youtube.com/watch?v=HNkbG3KsY84

I hope this helps in some way. :)

Davis

On Sun, Mar 27, 2011 at 5:35 PM, Sergey Kurdakov wrote:

> Hi Suvro,
>
>
> I also suggest you look at following links
>
>
>
> http://blenderartists.org/forum/showthread.php?207281-Using-OSC-in-Blender-2.5-Game-Engine-(with-Kinect-captured-data)
> here a script to import animation data is developed ( based on Nite etc )
>
> and papers to estimate skeleton based on my suggestions ( two Kinects )
>
> http://www.andreagiachetti.it/ActiveSkel/lcg_mirage2009.pdf
> http://www.win.tue.nl/~alext/ALEX/PAPERS/VisSym02/dskel.pdf
> http://alexandria.tue.nl/extra1/wskrap/publichtml/200638.pdf
> http://iwi.eldoc.ub.rug.nl/FILES/root/2008/LNCSReniers/2008LNCSReniers.pdf
>
> Regards
> Sergey
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal

[philipp oeser]

in your proposal you mention NITE being open source. cant find the info right 
now (not in front of my computer) but i am pretty sure it is not. they only 
provide a licensce key for free. will dig out the license tomorrow if i can 
find it.

good luck anyways, its a very interesting field to work in.


___
NEU: FreePhone - kostenlos mobil telefonieren und surfen!   

Jetzt informieren: http://produkte.web.de/go/webdefreephone
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSOC Proposal

[Dalai Felinto via Bf-committers]

Hi Anisha,

The skills you presented are traversal to all the existing proposals.
What I recommend is for you to find an area you are more familiar with
(or interested on) within Blender and think about a project for that
area.

-Dalai-

Dalai Felinto - da...@blender.org - www.blender.org
Blender Development Coordinator

Em ter., 24 de mar. de 2020 às 19:15, ANISHA JAIN via Bf-committers
 escreveu:
>
> Hey,
>
> I am Anisha Jain. I am studying in the pre-final year in CSE, at National
> Institute of Technology, Warangal.
> I saw that Blender is listed as one of the organizations at GSOC.
> I have recently started working on Blender and am learning modelling on it.
> And thus was very excited to see Blender listed at GSOC.
> But when I thought of doing research to find out which project I would like
> to work on I got confused among the sea of things that were present on the
> web pages.
>
> I am specifying my skill set below and I would be grateful if you could
> guide me to project that I can do.
> C, C++, Python, Java, C#, JS, React, PHP, HTML, CSS, ML, Deeplearning
> PS: I  am ready to learn any new skill that might be required.
> I have worked at Microsoft for a summer internship
> Hoping to hear from you soon
>
> Thanks and Regards
> Anisha
> [image: cloudHQ]
> 
> Powered
> by
> cloudHQ
> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: NURBS

[Antony Riakiotakis]

Hi,

I would add the proposal in the GSOC site and we can do a discussion there.
The proposal is not bad but I would add some additional information (which
you should be able in our template in the GSOC site).


On 17 March 2014 09:49, Jonathan deWerd  wrote:

> Feedback is welcome, but I'm really looking for a mentor :)
>
> https://dl.dropboxusercontent.com/u/8406827/NURBS_GSoC.pdf
>
> I emailed Laurynas Duburas (the 2005 NURBS GSoC student) and Emmanuel
> Stone (the 2009 NURBS push guy) on Friday. Neither has responded yet :(
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: NURBS

[Ton Roosendaal]

Hi Jonathan,

I have seen people work on this topic in the past 10 years, yet nobody could 
deliver something more usable than what I did in the 90ies... what is still in 
Blender now. And what I consider not usable either.

For me then the logical question is this: why even bother about Nurbana? That 
code is also from the 90ies, it is unsupported for 15 years, and I rather only 
accept a GSoC project from someone when he/she can become a reliable maintainer 
for it.

Alternative: check on what we need to do for our Curve/Surface object and tools 
and make a plan of action what to code?

Or: ditch this whole NURBS thing, it's ancient, it very hard to make usable and 
far too technical for artists. Everyone's using hybrid methods (using subsurf 
approach) now. I know Adesk bought the T-spline, but something similar would be 
great to look into.

NURBS is also something you can bedtter hide 'under the hood' and then make 
great tools for artists to help them modeling. If you look at Rhino or Maya you 
can see how they handle it. Which is: tools, tools, and tools. Not technology.

Or, just adding B-spline surfaces (like LW, etc) would make Blender surfaces so 
much more usable...

I miss this kind of insight or analysis in the proposal. Are you really 
familiar with the technology? With subsurf, t-spline, nurbs, and all these 
parametric curve families?

-Ton-


Ton Roosendaal  -  t...@blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



On 17 Mar, 2014, at 8:49, Jonathan deWerd wrote:

> Feedback is welcome, but I’m really looking for a mentor :)
> 
> https://dl.dropboxusercontent.com/u/8406827/NURBS_GSoC.pdf
> 
> I emailed Laurynas Duburas (the 2005 NURBS GSoC student) and Emmanuel Stone 
> (the 2009 NURBS push guy) on Friday. Neither has responded yet :(
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: NURBS

[Mango Jambo]

Every time I see someone suggesting to get Nurbs working in Blender I think
it is a good thing to see devs getting attention in the way we would shape
things in Blender, using different workflows from what we are use to. It is
a good thing. But I agree with Ton that tools, new or improved, can give us
the same effect with a lower cost.
In other hand, a way to deal with shapes in Blender would be great, but,
IMHO,  not necessarily using Nurbs. I would like to suggest you to check
this link
http://www.fxguide.com/featured/pixars-opensubdiv-v2-a-detailed-look/ . May
be an implementing opensubdiv would give us a greater addition for Blender.
But I'm just an artist. For me it's easy to suggest anything, right? ;)

Cheerios

Moraes Jr - aka mangojambo
Animator & 3D Artist
+55 43 88133399 


On 17 March 2014 08:36, Ton Roosendaal  wrote:

> Hi Jonathan,
>
> I have seen people work on this topic in the past 10 years, yet nobody
> could deliver something more usable than what I did in the 90ies... what is
> still in Blender now. And what I consider not usable either.
>
> For me then the logical question is this: why even bother about Nurbana?
> That code is also from the 90ies, it is unsupported for 15 years, and I
> rather only accept a GSoC project from someone when he/she can become a
> reliable maintainer for it.
>
> Alternative: check on what we need to do for our Curve/Surface object and
> tools and make a plan of action what to code?
>
> Or: ditch this whole NURBS thing, it's ancient, it very hard to make
> usable and far too technical for artists. Everyone's using hybrid methods
> (using subsurf approach) now. I know Adesk bought the T-spline, but
> something similar would be great to look into.
>
> NURBS is also something you can bedtter hide 'under the hood' and then
> make great tools for artists to help them modeling. If you look at Rhino or
> Maya you can see how they handle it. Which is: tools, tools, and tools. Not
> technology.
>
> Or, just adding B-spline surfaces (like LW, etc) would make Blender
> surfaces so much more usable...
>
> I miss this kind of insight or analysis in the proposal. Are you really
> familiar with the technology? With subsurf, t-spline, nurbs, and all these
> parametric curve families?
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> On 17 Mar, 2014, at 8:49, Jonathan deWerd wrote:
>
> > Feedback is welcome, but I’m really looking for a mentor :)
> >
> > https://dl.dropboxusercontent.com/u/8406827/NURBS_GSoC.pdf
> >
> > I emailed Laurynas Duburas (the 2005 NURBS GSoC student) and Emmanuel
> Stone (the 2009 NURBS push guy) on Friday. Neither has responded yet :(
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: NURBS

[Jonathan deWerd]

On Mar 17, 2014, at 7:36 AM, Ton Roosendaal  wrote:

> Hi Jonathan,
> 
> I have seen people work on this topic in the past 10 years, yet nobody could 
> deliver something more usable than what I did in the 90ies... what is still 
> in Blender now. And what I consider not usable either.
Ah, so you did write the original NURBS code! Yes it is really too bad what 
happened to the 2 previous efforts to improve it. I haven’t been able to 
contact Emmanuel or Laurynas. Any insight onto what prevented them from 
merging? Did they just never get their code to a stable state that would be a 
net feature addition?

> For me then the logical question is this: why even bother about Nurbana? That 
> code is also from the 90ies, it is unsupported for 15 years, and I rather 
> only accept a GSoC project from someone when he/she can become a reliable 
> maintainer for it.
The only reason to use nurbana is to take advantage of estone’s efforts. He got 
within throwing distance to 1 of 2 “big picture goals” my proposal mentioned 
(namely, .3dm import/export). He posted links to working binaries supporting 
curve trimming (the holdup for openNURBS, which gives .3dm import/export), so I 
know he wasn’t exaggerating about the progress. However, given that they’re MIA 
and you understand the inner workings of the current NURBS implementation, I 
tend to agree it might be wiser to ditch the old nurbs branch and start from 
trunk. There could be nasty structural bugs in the nurbs branch.

As for becoming maintainer, I do have the mathematical background to debug 
issues, understand the literature, and plan+code an eventual transition to 
T-Splines (or whatever we decide on). It’s the responsibility that I’m worried 
about. I would need to put out fires and do the occasional migration, on top of 
gradual long-term work (which I could adapt to my schedule and would not be a 
problem). It doesn’t sound too bad but I don’t have a good feel for how 
demanding the “putting out fires” part would be. Then again, I have to take on 
responsibility some time, and this is not a bad way to do it.

It’s easier to say “yes” to maintainer responsibility if I code from trunk 
rather than rebasing nurbana, since in that case I’ll be familiar with all the 
code.


> Alternative: check on what we need to do for our Curve/Surface object and 
> tools and make a plan of action what to code?
Sure, I can adapt the proposal relatively easily to include specific features 
from the nurbs branch rather than grouping them under “rebasing nurbana". Most 
of the “small features” I proposed were actually based on the current build, so 
this will largely involve deleting references to nurbana :)

> Or: ditch this whole NURBS thing, it's ancient, it very hard to make usable 
> and far too technical for artists. Everyone's using hybrid methods (using 
> subsurf approach) now. I know Adesk bought the T-spline, but something 
> similar would be great to look into.
Yes, it looks like artists have moved to Catmull limit surfaces (if they ever 
heavily used NURBS at all). CC surfaces are superior to NURBS (but not 
T-Spline) in terms of topological refinement. I’ve seen the opensubdiv demo, 
very impressive!  But CAD people still need NURBS compatibility. I know 
B-Splines are a subset of Catmull surfaces, but are rational B-splines a subset 
of Catmull surfaces with weights / sharpness factors / something? In any case, 
I’m pretty sure nonuniform rational B-splines aren’t a subset. We’d have to 
implement something like this to be compatible with NURBS: 
http://dl.acm.org/citation.cfm?id=1138455

That’s doable, but it may be easier and better to implement an unpatented 
T-spline data structure (I think I found one, but I haven’t digested the patent 
and the new paper enough to be sure) or perhaps another “NURBS+” surface, like 
the “extremum point NURBS” that interfaces well with poly meshes (haven’t read 
about it yet, terminology or details might be off). If you’re willing to let me 
have a “literature week” in the GSoC I can make a big matrix with all the 
options. I can’t have the matrix ready by Friday when proposals are due, 
however, and I still consider NURBS interoperability a constraint, since that’s 
the angle my personal motivation comes from.

Next-gen Surface + NURBS import/export + itch-scratches (“small features”) + 
key tools (chamfer/fillet, maybe even booleans)

is quite possibly too much for a GSoC.


> NURBS is also something you can bedtter hide 'under the hood' and then make 
> great tools for artists to help them modeling. If you look at Rhino or Maya 
> you can see how they handle it. Which is: tools, tools, and tools. Not 
> technology.
Agreed 100%. This is my weak spot: I’m a math&code guy, I have yet to learn 
which NURBS tools are the most useful for artists (I use them to prove things 
about “next-gen” finite element methods, I haven’t used them to build 
anything). Know anyone I could ask for advice on prioritizing tools? Rhino has 
a no

[Bf-committers] GSoC Proposal: Unit Testing

[Leif Andersen]

Hello, I am interested in participating in this years GSoC project.  In
particular, Unit testing.  An area that I though Unit tests would be good
was the API, but I'm very open to suggestions of any type.  I have attached
a prototype of my proposal, if anyone is willing to look at it, and give
constructive feedback, that would be greatly appreciated.  I am likely going
to change the bio at the end, as by the time Google will start accepting
applications, I will be done with the current projects I mention.

Again, thank you for your feedback.

*Development of Unit Tests for the Blender 2.5 API*


 *Name*

Leif Andersen


 *Email/IRC/WWW*

Emain – l...@leifandersen.net/leif.a.ander...@gmail.com/tbol3...@gmail.com

IRC – Leif/LeifAndersen

WWW – http://leifandersen.net


 *Synopsis*

* *Unit Testing is a very powerful tool used to determine the accuracy of
code components. While it is not generally used to test how various
desperate components of a project interact with each other directly, it can
be used to make sure that individual components are working properly, even
when components from different areas of the project are changed. For smaller
projects, and for components that are directly viewable to the user, this is
not a necessity. If there is a bug, it is directly viewable. However, for
larger projects, especially to portions of it that are hidden to the user,
this become very important. Unit testing helps developers of the project
determine which component the problems are coming from.

The goal of this project is to provide Unit Tests for all of the underlying
parts of the Blender API. Furthermore, if time permits, this project will
attempt to clean up the more stable portions of the Blender API, and expand
upon the current state of Blender development documentation.


 *Benefits to Blender*

According to the Blender code base,i <#127984db651a29d1_sdendnote1sym> there
currently is no main section for Unit Tests, leaving any tests in the code,
to be embedded within the files themselves. Furthermore, the main way to
determine how files are linked together, is to look at the makefiles
themselves, and to browse through the Blender code base. While this can be a
little daunting to new developers, the main problem is that this makes it
harder for regular contributers to test every component to make sure that
their slight changes to the code doesn't break anything.

This means that the current developers of Blender, especially the ones
working on the API, can spend more time making the code better, and less
time searching to find where their bugs are hidden. This is especially
useful for Blender with it's larger emphasis on the API. With lots of
development going on in that area, unit tests will be a valuable asset to
the Blender code base.


 *Deliverables*

By the end of this project, there will a simple set of tests that developers
can run to ensure that their modifications to the code did not change
anything major. Furthermore, these tests will give robust information as to
where the error occurs, to aid in the removal of any bugs. Finally, these
tests should be reliantly fast to run, and be built to be tested on both a
modular, and holistic level. That way the tests can be run often by the
developers, if they so choose to, but have the ability to perform all of the
tests with a simple button, when needed. This is useful so that the
developer need not completely recompile Blender, or the current module being
worked upon, while the work is done. Which should increase the speed of
development.

These tests will be placed in their own folder, or possibly, spread
throughout the code based delimited from the rest of the code.
Alternatively, the tests could be stored in a different section altogether
outside of the main blender svn folder. However, it would be useful to get
any changes made to the tests, whenever a developer gets the latest code
base.

These tests can be run either as the developer works on the project, or it
can happen as any new patches are committed into the code base.


 *Project Details*

CTestii <#127984db651a29d1_sdendnote2sym> is a powerful tool set which can
be used for generating test files. This is especially useful as blender is
already using CMake as an option to compile blender with. CDash can be used
as a straightforward front end, so the programmer can easily see the results
of the tests.

The first phase of the project is to create the Unit tests. They should test
the API for everything reasonably conceivably thrown at it, even if it is an
invalid parameter. This is important so developers, especially plugin
developers who are still new to the API, will get useful information back
when the put improper parameters into the function. The tests will not be
compiled together into a simple set of tests during this phase. Also, during
this phase, the tests will likely exist outside of the main trunk.

The second phase is to incorporate all of the tests into a concise package,
to m

[Bf-committers] GSOC proposal for review

[shuvro sarker]

Hi,

This is the link of two GSOC proposals of mine.

http://wiki.blender.org/index.php/User:Shuvro

Expecting your review and comments.
Thanks.

Shuvro
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal - GE Nodes

[Sven von Brand Laredo]

Hi,
 I would like to participate in the GSoC, specially in the Game 
Engine Nodes, I've participated a bit in the community before. Haven't 
participated much in the development of Blender, but would like to 
change that.

This past Summer (Chilean Summer, January-February) I did and internship 
in a Game Development Company and worked a lot in C++. I'm currently a 
last year student from Computer Science Engineering and would like to 
participate in the node editor for the game engine as I've work a lot 
with the Game Engine for school projects and doing other things and 
would love to have that functionality in Blender for myself and for 
everyone interested :).

So could anyone help me get into this, I read the page for the node 
editor, it looks like a lot of work, but I think something like what's 
proposed could be done.

Any tips you could give me to help me get my proposal to a good start?

Thank you in advance

-- 
Sven von Brand Laredo
Estudiante de Ing. Civil Informatica, UTFSM
Fedora Ambassador for Chile

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC proposal - GE Nodes

[Sven von Brand Laredo]

Hi all
I submitted my proposal to google
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/svbrand/1#
if you can't see it's also here:
http://wiki.blender.org/index.php/User:Svbrand

I couldn't send it before, but everyone in the IRC helped me finishing 
the proposal.
special Thanks to Benoit!

-- 
Sven von Brand
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSOC proposal for review

[Dalai Felinto]

Hi Shuvro,

1) Extending Blender Game Engine Python API:
I think that your idea may be too specific for a kind of game. Although it
looks like an interesting project I'm not sure it should belong to the core
of the BGE code. Assuming they could be implemented as external plugins or
python scripts I don't see this as a gsoc project (may be because I don't
use BGE for actual games, so don't know. would like to hear from others
here).

2) Automatic seam creation for UV unwrapping
That looks like the kind of project that fits well in the scope of a gsoc. I
can't comment much because I'm not acquitanced with the mesh and uv code of
Blender.

my 2 cents, good luck !
Dalai

2010/4/2 shuvro sarker 

> Hi,
>
> This is the link of two GSOC proposals of mine.
>
> http://wiki.blender.org/index.php/User:Shuvro
>
> Expecting your review and comments.
> Thanks.
>
> Shuvro
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Keir Mierle]

Congratulations Leif for having your proposal accepted!

I thought I would drop in to plug the Google Test unittesting framework.
Yes, it's C++, but it has some features like automatic test registration and
concise syntax (among others) that make it superior to the pure C
frameworks. Furthermore, I am a committer on the project and offer my
support. I will be available for the duration of GSoC. I can also help with
build integration, as I've integrated Google Test with several projects.

http://code.google.com/p/googletest/

I'm happy answer any questions.

Keir


On Thu, Mar 25, 2010 at 7:29 PM, Leif Andersen wrote:

> Hello, I am interested in participating in this years GSoC project.  In
> particular, Unit testing.  An area that I though Unit tests would be good
> was the API, but I'm very open to suggestions of any type.  I have attached
> a prototype of my proposal, if anyone is willing to look at it, and give
> constructive feedback, that would be greatly appreciated.  I am likely
> going
> to change the bio at the end, as by the time Google will start accepting
> applications, I will be done with the current projects I mention.
>
> Again, thank you for your feedback.
>
> *Development of Unit Tests for the Blender 2.5 API*
>
>
>  *Name*
>
> Leif Andersen
>
>
>  *Email/IRC/WWW*
>
> Emain – l...@leifandersen.net/leif.a.ander...@gmail.com/tbol3...@gmail.com
>
> IRC – Leif/LeifAndersen
>
> WWW – http://leifandersen.net
>
>
>  *Synopsis*
>
> * *Unit Testing is a very powerful tool used to determine the accuracy of
> code components. While it is not generally used to test how various
> desperate components of a project interact with each other directly, it can
> be used to make sure that individual components are working properly, even
> when components from different areas of the project are changed. For
> smaller
> projects, and for components that are directly viewable to the user, this
> is
> not a necessity. If there is a bug, it is directly viewable. However, for
> larger projects, especially to portions of it that are hidden to the user,
> this become very important. Unit testing helps developers of the project
> determine which component the problems are coming from.
>
> The goal of this project is to provide Unit Tests for all of the underlying
> parts of the Blender API. Furthermore, if time permits, this project will
> attempt to clean up the more stable portions of the Blender API, and expand
> upon the current state of Blender development documentation.
>
>
>  *Benefits to Blender*
>
> According to the Blender code base,i <#127984db651a29d1_sdendnote1sym>
> there
> currently is no main section for Unit Tests, leaving any tests in the code,
> to be embedded within the files themselves. Furthermore, the main way to
> determine how files are linked together, is to look at the makefiles
> themselves, and to browse through the Blender code base. While this can be
> a
> little daunting to new developers, the main problem is that this makes it
> harder for regular contributers to test every component to make sure that
> their slight changes to the code doesn't break anything.
>
> This means that the current developers of Blender, especially the ones
> working on the API, can spend more time making the code better, and less
> time searching to find where their bugs are hidden. This is especially
> useful for Blender with it's larger emphasis on the API. With lots of
> development going on in that area, unit tests will be a valuable asset to
> the Blender code base.
>
>
>  *Deliverables*
>
> By the end of this project, there will a simple set of tests that
> developers
> can run to ensure that their modifications to the code did not change
> anything major. Furthermore, these tests will give robust information as to
> where the error occurs, to aid in the removal of any bugs. Finally, these
> tests should be reliantly fast to run, and be built to be tested on both a
> modular, and holistic level. That way the tests can be run often by the
> developers, if they so choose to, but have the ability to perform all of
> the
> tests with a simple button, when needed. This is useful so that the
> developer need not completely recompile Blender, or the current module
> being
> worked upon, while the work is done. Which should increase the speed of
> development.
>
> These tests will be placed in their own folder, or possibly, spread
> throughout the code based delimited from the rest of the code.
> Alternatively, the tests could be stored in a different section altogether
> outside of the main blender svn folder. However, it would be useful to get
> any changes made to the tests, whenever a developer gets the latest code
> base.
>
> These tests can be run either as the developer works on the project, or it
> can happen as any new patches are committed into the code base.
>
>
>  *Project Details*
>
> CTestii <#127984db651a29d1_sdendnote2sym> is a powerful tool set which can
> be used for generating test files. T

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Leif Andersen]

Okay, I'll take a look into it.  The only think that I may be worried about
is the license, I'm not sure how that would work for unit testing, so I'm
not sure if the BSD license would be comparable with a GPL project.

~Leif Andersen

--
That was easy:
http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton


On Wed, May 5, 2010 at 04:23, Keir Mierle  wrote:

> Congratulations Leif for having your proposal accepted!
>
> I thought I would drop in to plug the Google Test unittesting framework.
> Yes, it's C++, but it has some features like automatic test registration
> and
> concise syntax (among others) that make it superior to the pure C
> frameworks. Furthermore, I am a committer on the project and offer my
> support. I will be available for the duration of GSoC. I can also help with
> build integration, as I've integrated Google Test with several projects.
>
> http://code.google.com/p/googletest/
>
> I'm happy answer any questions.
>
> Keir
>
>
> On Thu, Mar 25, 2010 at 7:29 PM, Leif Andersen  >wrote:
>
> > Hello, I am interested in participating in this years GSoC project.  In
> > particular, Unit testing.  An area that I though Unit tests would be good
> > was the API, but I'm very open to suggestions of any type.  I have
> attached
> > a prototype of my proposal, if anyone is willing to look at it, and give
> > constructive feedback, that would be greatly appreciated.  I am likely
> > going
> > to change the bio at the end, as by the time Google will start accepting
> > applications, I will be done with the current projects I mention.
> >
> > Again, thank you for your feedback.
> >
> > *Development of Unit Tests for the Blender 2.5 API*
> >
> >
> >  *Name*
> >
> > Leif Andersen
> >
> >
> >  *Email/IRC/WWW*
> >
> > Emain –
> l...@leifandersen.net/leif.a.ander...@gmail.com/tbol3...@gmail.com
> >
> > IRC – Leif/LeifAndersen
> >
> > WWW – http://leifandersen.net
> >
> >
> >  *Synopsis*
> >
> > * *Unit Testing is a very powerful tool used to determine the accuracy of
> > code components. While it is not generally used to test how various
> > desperate components of a project interact with each other directly, it
> can
> > be used to make sure that individual components are working properly,
> even
> > when components from different areas of the project are changed. For
> > smaller
> > projects, and for components that are directly viewable to the user, this
> > is
> > not a necessity. If there is a bug, it is directly viewable. However, for
> > larger projects, especially to portions of it that are hidden to the
> user,
> > this become very important. Unit testing helps developers of the project
> > determine which component the problems are coming from.
> >
> > The goal of this project is to provide Unit Tests for all of the
> underlying
> > parts of the Blender API. Furthermore, if time permits, this project will
> > attempt to clean up the more stable portions of the Blender API, and
> expand
> > upon the current state of Blender development documentation.
> >
> >
> >  *Benefits to Blender*
> >
> > According to the Blender code base,i <#127984db651a29d1_sdendnote1sym>
> > there
> > currently is no main section for Unit Tests, leaving any tests in the
> code,
> > to be embedded within the files themselves. Furthermore, the main way to
> > determine how files are linked together, is to look at the makefiles
> > themselves, and to browse through the Blender code base. While this can
> be
> > a
> > little daunting to new developers, the main problem is that this makes it
> > harder for regular contributers to test every component to make sure that
> > their slight changes to the code doesn't break anything.
> >
> > This means that the current developers of Blender, especially the ones
> > working on the API, can spend more time making the code better, and less
> > time searching to find where their bugs are hidden. This is especially
> > useful for Blender with it's larger emphasis on the API. With lots of
> > development going on in that area, unit tests will be a valuable asset to
> > the Blender code base.
> >
> >
> >  *Deliverables*
> >
> > By the end of this project, there will a simple set of tests that
> > developers
> > can run to ensure that their modifications to the code did not change
> > anything major. Furthermore, these tests will give robust information as
> to
> > where the error occurs, to aid in the removal of any bugs. Finally, these
> > tests should be reliantly fast to run, and be built to be tested on both
> a
> > modular, and holistic level. That way the tests can be run often by the
> > developers, if they so choose to, but have the ability to perform all of
> > the
> > tests with a simple button, when needed. This is useful so that the
> > developer need not completely recompile Blender, or the current module
> > being
> > worked upon, while the work is done. Which should increase the speed of
> > development.
> >
> > These tests will be placed in their own f

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Tom M]

On Wed, May 5, 2010 at 1:41 PM, Leif Andersen  wrote:
> Okay, I'll take a look into it.  The only think that I may be worried about
> is the license, I'm not sure how that would work for unit testing, so I'm
> not sure if the BSD license would be comparable with a GPL project.

BSD, MIT, zlib, LGPL are all GPL compatible.

LetterRip


>
> ~Leif Andersen
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Leif Andersen]

Great, thanks, that's good information to have.

~Leif Andersen

--
That was easy:
http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton


On Wed, May 5, 2010 at 15:51, Tom M  wrote:

> On Wed, May 5, 2010 at 1:41 PM, Leif Andersen 
> wrote:
> > Okay, I'll take a look into it.  The only think that I may be worried
> about
> > is the license, I'm not sure how that would work for unit testing, so I'm
> > not sure if the BSD license would be comparable with a GPL project.
>
> BSD, MIT, zlib, LGPL are all GPL compatible.
>
> LetterRip
>
>
> >
> > ~Leif Andersen
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Leif Andersen]

Okay, I have spent several hours looking into this.  I do like how the
framework works, however, I still haven't gotten it to actually compile
anything (not even their samples, so I'm thinking I've got the framework
compiled incorrectly).  It also seems like this is designed to be used
directly by the end programmer, rather than being plugged into another
framework such as Ctest (which is what I was considering doing, as cmake is
already used), but I could be wrong on that.

However, I would like to get the general mood of the developers on having a
C++ testing framework.  Is it proffered, acceptable but not optimal, or is
a definite no (or something else).  While the majority of the code is
written in C (except for parts written in python), there are a few bits here
and there in C++.

Anyway, I appreciate your opinions.

~Leif Andersen

--
That was easy:
http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton


On Wed, May 5, 2010 at 17:51, Leif Andersen wrote:

> Great, thanks, that's good information to have.
>
> ~Leif Andersen
>
> --
> That was easy:
> http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton
>
>
> On Wed, May 5, 2010 at 15:51, Tom M  wrote:
>
>> On Wed, May 5, 2010 at 1:41 PM, Leif Andersen 
>> wrote:
>> > Okay, I'll take a look into it.  The only think that I may be worried
>> about
>> > is the license, I'm not sure how that would work for unit testing, so
>> I'm
>> > not sure if the BSD license would be comparable with a GPL project.
>>
>> BSD, MIT, zlib, LGPL are all GPL compatible.
>>
>> LetterRip
>>
>>
>> >
>> > ~Leif Andersen
>> >
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Keir Mierle]

On Fri, May 7, 2010 at 2:37 PM, Leif Andersen wrote:

> Okay, I have spent several hours looking into this.  I do like how the
> framework works, however, I still haven't gotten it to actually compile
> anything (not even their samples, so I'm thinking I've got the framework
> compiled incorrectly).


If you can post errors, I may be able to help. Generally installation should
be trivial, so I'm a surprised you had issues. If it's something that needs
to be fixed in Google Test's source or docs, I can do that, so please follow
up.


>  It also seems like this is designed to be used
> directly by the end programmer, rather than being plugged into another
> framework such as Ctest (which is what I was considering doing, as cmake is
> already used), but I could be wrong on that.
>

I use Google Test and CTest in my own open source project, libmv, to great
effect.

http://libmv.googlecode.com/

Note that CTest is not a unit testing framework. All CTest does is offer the
ability to invoke binaries specified in a the CMakeLists.txt files, and
report success or fail on a per-binary basis depending on whether the binary
had a non-zero exitcode.

Google Test is a unit testing framework, where you write many small tests,
each in a function, that get executed all at once in a single binary.
Generally, you would make one binary for a suite of tests. For example,
there would be a test binary for the sculpt code which has many
sculpt-related unit tests.


> However, I would like to get the general mood of the developers on having a
> C++ testing framework.  Is it proffered, acceptable but not optimal, or is
> a definite no (or something else).  While the majority of the code is
> written in C (except for parts written in python), there are a few bits
> here
> and there in C++.
>

Note that you don't have to *use* C++ at all to use the testing framework.
Here's a complete sample  that only has visible C++ in the main function,
which itself will not appear in the individual C++ test files.

#include 

TEST(MyTestGroup, EnsureThatFooReturnsPositive) {
  EXPECT_GE(foo(), 0);
}

// more tests here

int main(int argc, char **argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

If the main is already linked in elsewhere (as most projects do, see e.g.
libmv), then this reduces to just:

#include 

TEST(MyTestGroup, EnsureThatFooReturnsPositive) {
  EXPECT_GE(foo(), 0);
}

With any of the C based frameworks, either they require explicit
registration or some sort of nasty preprocessing hack in order to get this.

Keir

Anyway, I appreciate your opinions.
>
> ~Leif Andersen
>
> --
> That was easy:
> http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton
>
>
> On Wed, May 5, 2010 at 17:51, Leif Andersen  >wrote:
>
> > Great, thanks, that's good information to have.
> >
> > ~Leif Andersen
> >
> > --
> > That was easy:
> > http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton
> >
> >
> > On Wed, May 5, 2010 at 15:51, Tom M  wrote:
> >
> >> On Wed, May 5, 2010 at 1:41 PM, Leif Andersen <
> leif.a.ander...@gmail.com>
> >> wrote:
> >> > Okay, I'll take a look into it.  The only think that I may be worried
> >> about
> >> > is the license, I'm not sure how that would work for unit testing, so
> >> I'm
> >> > not sure if the BSD license would be comparable with a GPL project.
> >>
> >> BSD, MIT, zlib, LGPL are all GPL compatible.
> >>
> >> LetterRip
> >>
> >>
> >> >
> >> > ~Leif Andersen
> >> >
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Leif Andersen]

I have a feeling it is me who boarked my installation, not a problem with
the framework itself.  (I've tried both ubuntu's pre-built binaries, as well
as the files from the link you gave me).  I think it's on there somehow,
because when I do a tab-completion for the text gtest, I get: gtest-config
 gtester gtester-report.  Also, eclipse seems to think
 exists.

I basically built sample 1, and here is an error I get:
Multiple markers at this line
- undefined reference to `testing::Test::Test()'
 - undefined reference to `testing::internal::GetTestTypeId()'
- undefined reference to `testing::internal::MakeAndRegisterTestInfo(char
const*, char
 const*, char const*, char const*, void const*, void (*)(), void (*)(),
 testing::internal::TestFactoryBase*)'

on line 79: TEST(FactorialTest, Negative) {


I basically get that for every method I use.  (I also get errors saying
things like EXPECT_EQ doesn't exist, but it seems to stem from this).  Also
note that I'm using eclipse with gcc to compile the code (as I didn't want
to build a makefile for the two other files in the sample).This error
causes me to think that it's improperly linked somehow.  However,  line 48
says: #include , and eclipse isn't complaining about that
code not existing, which causes me to think that I somehow boarked my
install.  (if I did, it's not the end of the world, I was planning on
reloading this computer in about a week anyway, I can just move that up to
tonight or tomorrow).

Note that CTest is not a unit testing framework. All CTest does is offer the
> ability to invoke binaries specified in a the CMakeLists.txt files, and
> report success or fail on a per-binary basis depending on whether the
> binary
> had a non-zero exitcode.


Erm, that's what I meant, I just couldn't find an eloquent way of saying it.
 Thank you though.  Also, if calling it a unit test framework is a bad idea,
what is a good term for it, or is that the most concise way to say was CTest
is?

Note that you don't have to *use* C++ at all to use the testing framework.
> Here's a complete sample  that only has visible C++ in the main function,
> which itself will not appear in the individual C++ test files.


Yes, at least I thought all C code (well, except for the extremely specific
portions of C code),  were comparable with C++, thus C++ is a superset of C.
 What I was mainly trying to say is how happy would everyone be if the unit
tests were written in C++.  Although now that I think about it, it's
probably not too big of a deal.  There are already portions of it written in
C++, so I wouldn't imagine that using gtest would add much baggage (or am I
wrong to think that?)

Again, thank you for your help.  And I'm sorry if this email is a bit
difficult to read, I wrote it from the inside out.

~Leif Andersen

--
That was easy:
http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton


On Fri, May 7, 2010 at 15:51, Keir Mierle  wrote:

> On Fri, May 7, 2010 at 2:37 PM, Leif Andersen  >wrote:
>
> > Okay, I have spent several hours looking into this.  I do like how the
> > framework works, however, I still haven't gotten it to actually compile
> > anything (not even their samples, so I'm thinking I've got the framework
> > compiled incorrectly).
>
>
> If you can post errors, I may be able to help. Generally installation
> should
> be trivial, so I'm a surprised you had issues. If it's something that needs
> to be fixed in Google Test's source or docs, I can do that, so please
> follow
> up.
>
>
> >  It also seems like this is designed to be used
> > directly by the end programmer, rather than being plugged into another
> > framework such as Ctest (which is what I was considering doing, as cmake
> is
> > already used), but I could be wrong on that.
> >
>
> I use Google Test and CTest in my own open source project, libmv, to great
> effect.
>
> http://libmv.googlecode.com/
>
> Note that CTest is not a unit testing framework. All CTest does is offer
> the
> ability to invoke binaries specified in a the CMakeLists.txt files, and
> report success or fail on a per-binary basis depending on whether the
> binary
> had a non-zero exitcode.
>
> Google Test is a unit testing framework, where you write many small tests,
> each in a function, that get executed all at once in a single binary.
> Generally, you would make one binary for a suite of tests. For example,
> there would be a test binary for the sculpt code which has many
> sculpt-related unit tests.
>
>
> > However, I would like to get the general mood of the developers on having
> a
> > C++ testing framework.  Is it proffered, acceptable but not optimal, or
> is
> > a definite no (or something else).  While the majority of the code is
> > written in C (except for parts written in python), there are a few bits
> > here
> > and there in C++.
> >
>
> Note that you don't have to *use* C++ at all to use the testing framework.
> Here's a complete sample  that only has visible C++ in the main funct

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Keir Mierle]

On Fri, May 7, 2010 at 4:09 PM, Leif Andersen wrote:

> I have a feeling it is me who boarked my installation, not a problem with
> the framework itself.  (I've tried both ubuntu's pre-built binaries, as
> well
> as the files from the link you gave me).  I think it's on there somehow,
> because when I do a tab-completion for the text gtest, I get: gtest-config
>  gtester gtester-report.  Also, eclipse seems to think
>  exists.
>
> I basically built sample 1, and here is an error I get:
>

Can you also include the command line to build?


> Multiple markers at this line
> - undefined reference to `testing::Test::Test()'
>  - undefined reference to `testing::internal::GetTestTypeId()'
> - undefined reference to `testing::internal::MakeAndRegisterTestInfo(char
> const*, char
>  const*, char const*, char const*, void const*, void (*)(), void (*)(),
>  testing::internal::TestFactoryBase*)'
>

This looks like a straigtforward missing library problem when linking. Did
you link gtest? I believe -lgtest will do, provided your library search
paths are set correctly.


> on line 79: TEST(FactorialTest, Negative) {
>
>
> I basically get that for every method I use.  (I also get errors saying
> things like EXPECT_EQ doesn't exist, but it seems to stem from this).  Also
> note that I'm using eclipse with gcc to compile the code (as I didn't want
> to build a makefile for the two other files in the sample).


It's a one liner

g++ -o example example.cc -lgtest


>  This error
> causes me to think that it's improperly linked somehow.  However,  line 48
> says: #include , and eclipse isn't complaining about that
> code not existing, which causes me to think that I somehow boarked my
> install.


Note that #include does not imply link. You need to include the right
headers for the object file to compile (the .o) and then you need the right
libraries specified with -lfoo when linking to get the final ELF binary.

I suggest using the command line for a bit to make sure you understand how
the compiler and linker are different and how they work together. Otherwise,
trying to track down eclipse problems is really tough because there are
added layers of abstraction that hide the issues.

 (if I did, it's not the end of the world, I was planning on
> reloading this computer in about a week anyway, I can just move that up to
> tonight or tomorrow).
>
> Note that CTest is not a unit testing framework. All CTest does is offer
> the
> > ability to invoke binaries specified in a the CMakeLists.txt files, and
> > report success or fail on a per-binary basis depending on whether the
> > binary
> > had a non-zero exitcode.
>
>
> Erm, that's what I meant, I just couldn't find an eloquent way of saying
> it.
>  Thank you though.  Also, if calling it a unit test framework is a bad
> idea,
> what is a good term for it, or is that the most concise way to say was
> CTest
> is?
>

It's a test runner framework, or maybe a continuous build platform.


> Note that you don't have to *use* C++ at all to use the testing framework.
> > Here's a complete sample  that only has visible C++ in the main function,
> > which itself will not appear in the individual C++ test files.
>
>
> Yes, at least I thought all C code (well, except for the extremely specific
> portions of C code),  were comparable with C++, thus C++ is a superset of
> C.
>  What I was mainly trying to say is how happy would everyone be if the unit
> tests were written in C++.  Although now that I think about it, it's
> probably not too big of a deal.  There are already portions of it written
> in
> C++, so I wouldn't imagine that using gtest would add much baggage (or am I
> wrong to think that?)
>

Hopefully not. I could imagine objections to having to use C++ syntax to
write tests, but that's not the case here.


> Again, thank you for your help.  And I'm sorry if this email is a bit
> difficult to read, I wrote it from the inside out.
>

No problem!

Keir


>
> ~Leif Andersen
>
> --
> That was easy:
> http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton
>
>
> On Fri, May 7, 2010 at 15:51, Keir Mierle  wrote:
>
> > On Fri, May 7, 2010 at 2:37 PM, Leif Andersen  > >wrote:
> >
> > > Okay, I have spent several hours looking into this.  I do like how the
> > > framework works, however, I still haven't gotten it to actually compile
> > > anything (not even their samples, so I'm thinking I've got the
> framework
> > > compiled incorrectly).
> >
> >
> > If you can post errors, I may be able to help. Generally installation
> > should
> > be trivial, so I'm a surprised you had issues. If it's something that
> needs
> > to be fixed in Google Test's source or docs, I can do that, so please
> > follow
> > up.
> >
> >
> > >  It also seems like this is designed to be used
> > > directly by the end programmer, rather than being plugged into another
> > > framework such as Ctest (which is what I was considering doing, as
> cmake
> > is
> > > already used), but I could b

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Brecht Van Lommel]

Hi,

I think the direction of this project should also be discussed with
your mentor, but among the summer of code mentors I think we agreed
that it should be python based and not really fine grained unit tests
for C code. Unit testing specifically is not necessarily what we think
is the best idea, if it is the kind of thing that requires a lot of
effort to write and maintain as code changes. We want something that
allows us test as much as possible with as little effort as possible.

Instead you can think of things like:
* Regression testing of renders compared to existing version (compare pixels)
* Same for e.g. mesh tools (compare mesh topology)
* Importers/exporters testing if the result is the same
* Maybe even ecording user operations and then verifying if the result
is the same?
* Verify operators don't crash when run in different contexts
* Testing that using API functions/properties don't crash with various inputs
* Testing for NaN/Inf number results.
* Testing for memory leak error prints.

In fact just based on renders you can test if most modifiers, nodes,
constraints, particle options still work as before. Clearly this is
not as useful as fine-grained unit testing as you usually do with
toolkits like Google Test, but only a testing framework that is simple
and requires little work to maintain will actually be picked up by
developers. This leads a bit more to 'regression testing' maybe, but
many of the things that break can't be expressed easily as assertions
unless you write hundreds of thousands of lines of testing code.

Brecht.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Andrea Weikert]

Hi,

> Hi,
>
> I think the direction of this project should also be discussed with
> your mentor, but among the summer of code mentors I think we agreed
> that it should be python based and not really fine grained unit tests
> for C code. Unit testing specifically is not necessarily what we think
> is the best idea, if it is the kind of thing that requires a lot of
> effort to write and maintain as code changes. We want something that
> allows us test as much as possible with as little effort as possible.
>
>   
I think there might have been a slight misunderstanding. The proposal 
was listed as Unit Tests
even on our suggestion page and while I have said that we will evaluate 
at which level and to what
extent they can be added these are definitely different from end-to-end 
(regression) tests.
We will not add unit tests to each and every function (way over the 
scope of a GSOC project anyway ;)
and certainly add tests only to parts where the code is currently not 
very volatile and the API is mostly stable.
> Instead you can think of things like:
> * Regression testing of renders compared to existing version (compare pixels)
> * Same for e.g. mesh tools (compare mesh topology)
> * Importers/exporters testing if the result is the same
> * Maybe even ecording user operations and then verifying if the result
> is the same?
> * Verify operators don't crash when run in different contexts
> * Testing that using API functions/properties don't crash with various inputs
> * Testing for NaN/Inf number results.
> * Testing for memory leak error prints.
>   
While I agree that end-to-end tests like comparing renders are useful 
too, I don't think there is enough
substance in them for a GSOC project, as it's more installing a few 
tools, creating some .blend files and
comparing the output with previous version.

Unit tests are useful *during* development, to make sure new code 
doesn't break existing functionality.
They help pointing out to exactly the function/part of the code that 
doesn't run as expected in contrast to
a more coarse end-to-end test that tests the whole pipeline. Unit tests 
are meant to run fast (it is definitely
a goal to keep the running time of *all* the tests definitely under a 
minute and single test suites under 10 secs or so)
and thus can be run constantly like to make sure nothing breaks before I 
commit.

The end-to-end tests also run *much* more slowly than unit tests (at 
least as soon as some kind of render
is involved), so I don't believe they will be picked up by developers 
unless maybe shortly before a release.

> In fact just based on renders you can test if most modifiers, nodes,
> constraints, particle options still work as before. Clearly this is
> not as useful as fine-grained unit testing as you usually do with
> toolkits like Google Test, but only a testing framework that is simple
> and requires little work to maintain will actually be picked up by
> developers. This leads a bit more to 'regression testing' maybe, but
> many of the things that break can't be expressed easily as assertions
> unless you write hundreds of thousands of lines of testing code.
>
> Brecht.
>   
I understand that for developers who are not familiar with unit testing 
the fact that there is code required to
write the unit tests and some effort to maintain them might seem too 
much at first. I do hope to show with this project
that the effort to maintain them isn't really that much, since if you 
think about it, the only time a test needs to change
is when the API of a function changes. And this is something that we are 
moving to anyway - to have much more stable
internal APIs that likely won't change *that* much and I wouldn't 
propose to test every single internal function,
but test through the API that is exposed to other parts of Blender. In 
this light, if the API changes,
you'd probably have to change a few places anyway and updating the tests 
is then not that much more
compared to the normal development work.

 From my experience, having unit tests in place leads to code that is 
more bug free and stable and greatly reduces time spent debugging.
So in the end the tests should *save* time.
I actually don't think writing a small test takes more time than to add 
debug printf in strategic places and remove them later,
which so far has been probably the most used debugging tool. The only 
difference is that the unit tests would remain
as a permanent safety net and also act as a documentation on how the 
original coder expected the code to be used.
The tests will be kept separate from the "productive code", so as to not 
clutter it, though we will work out how to structure this
exactly as part of the GSOC project.

To allow all developers to gain experience, I suggested to Leif to 
first  look into specific areas that would benefit most from testing,
such as mesh tools or modifiers and write a small number of tests 
initially to get the framework and automatic running of the
tests in place. We wo

Re: [Bf-committers] GSoC Proposal: Unit Testing

[Leif Andersen]

Regarding the debate about what type of tests there will be, and the use of
C/C++/Python, I think that was covered sufficiently well on #blendercoders.
 Although, I'm not sure if #blendercoders has IRC logs.

 It's a one liner
>
> g++ -o example example.cc -lgtest

Well, that didn't work, nor did the 3 liner in the README file.

  g++ -I${GTEST_DIR}/include -I${GTEST_DIR} -c ${GTEST_DIR}/src/gtest-all.cc

  ar -rv libgtest.a gtest-all.o

   g++ -I${GTEST_DIR}/include path/to/your_test.cc libgtest.a -o your_test


After setting GTEST_DIR to be the folder where I downloaded the GTEST files
too, and replacing path/to/your_test.cc and your_test to the unit tests.
 Later, I also tried adding the classes that the tests relied upon, but that
didn't work.   However, using the makefile template, I finally was able to
get it to compile, and run.  Although I'm not entirely sure of what it's
doing. ;)  I guess I have more to learn.

Note that #include does not imply link. You need to include the right
> headers for the object file to compile (the .o) and then you need the right
> libraries specified with -lfoo when linking to get the final ELF binary.
>
> I suggest using the command line for a bit to make sure you understand how
> the compiler and linker are different and how they work together.
> Otherwise,
> trying to track down eclipse problems is really tough because there are
> added layers of abstraction that hide the issues.


Really?  #include doesn't imply a link, than what is it for?  (Or maybe it's
just me getting terminology wrong, again).   Anyway, can do, I am back in
the command line, and will wait until I think I've learned it before I go
back to an IDE to speed things up a bit.

Again, thank you everyone.

~Leif Andersen

--
That was easy:
http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton


On Sat, May 8, 2010 at 10:23, Andrea Weikert  wrote:

> Hi,
>
> > Hi,
> >
> > I think the direction of this project should also be discussed with
> > your mentor, but among the summer of code mentors I think we agreed
> > that it should be python based and not really fine grained unit tests
> > for C code. Unit testing specifically is not necessarily what we think
> > is the best idea, if it is the kind of thing that requires a lot of
> > effort to write and maintain as code changes. We want something that
> > allows us test as much as possible with as little effort as possible.
> >
> >
> I think there might have been a slight misunderstanding. The proposal
> was listed as Unit Tests
> even on our suggestion page and while I have said that we will evaluate
> at which level and to what
> extent they can be added these are definitely different from end-to-end
> (regression) tests.
> We will not add unit tests to each and every function (way over the
> scope of a GSOC project anyway ;)
> and certainly add tests only to parts where the code is currently not
> very volatile and the API is mostly stable.
> > Instead you can think of things like:
> > * Regression testing of renders compared to existing version (compare
> pixels)
> > * Same for e.g. mesh tools (compare mesh topology)
> > * Importers/exporters testing if the result is the same
> > * Maybe even ecording user operations and then verifying if the result
> > is the same?
> > * Verify operators don't crash when run in different contexts
> > * Testing that using API functions/properties don't crash with various
> inputs
> > * Testing for NaN/Inf number results.
> > * Testing for memory leak error prints.
> >
> While I agree that end-to-end tests like comparing renders are useful
> too, I don't think there is enough
> substance in them for a GSOC project, as it's more installing a few
> tools, creating some .blend files and
> comparing the output with previous version.
>
> Unit tests are useful *during* development, to make sure new code
> doesn't break existing functionality.
> They help pointing out to exactly the function/part of the code that
> doesn't run as expected in contrast to
> a more coarse end-to-end test that tests the whole pipeline. Unit tests
> are meant to run fast (it is definitely
> a goal to keep the running time of *all* the tests definitely under a
> minute and single test suites under 10 secs or so)
> and thus can be run constantly like to make sure nothing breaks before I
> commit.
>
> The end-to-end tests also run *much* more slowly than unit tests (at
> least as soon as some kind of render
> is involved), so I don't believe they will be picked up by developers
> unless maybe shortly before a release.
>
> > In fact just based on renders you can test if most modifiers, nodes,
> > constraints, particle options still work as before. Clearly this is
> > not as useful as fine-grained unit testing as you usually do with
> > toolkits like Google Test, but only a testing framework that is simple
> > and requires little work to maintain will actually be picked up by
> > developers. This leads a bit more to 'regression 

Re: [Bf-committers] GSoC proposal - GE Nodes

[Mitchell Stokes]

Hello,

Nodal Logic is a pretty big task. Mostly because of the all the design
decisions to get it "right". I'm in the #blendercoders IRC channel
(freenode) quite a bit using the nick Moguri. So, come find me if you
want to chat. Also, I'd recommend talking with Campbell (Ideasman).

Good luck!

--Mitchell Stokes (Moguri)

On Tue, Mar 29, 2011 at 7:17 PM, Sven von Brand Laredo
 wrote:
> Hi,
>     I would like to participate in the GSoC, specially in the Game
> Engine Nodes, I've participated a bit in the community before. Haven't
> participated much in the development of Blender, but would like to
> change that.
>
> This past Summer (Chilean Summer, January-February) I did and internship
> in a Game Development Company and worked a lot in C++. I'm currently a
> last year student from Computer Science Engineering and would like to
> participate in the node editor for the game engine as I've work a lot
> with the Game Engine for school projects and doing other things and
> would love to have that functionality in Blender for myself and for
> everyone interested :).
>
> So could anyone help me get into this, I read the page for the node
> editor, it looks like a lot of work, but I think something like what's
> proposed could be done.
>
> Any tips you could give me to help me get my proposal to a good start?
>
> Thank you in advance
>
> --
> Sven von Brand Laredo
> Estudiante de Ing. Civil Informatica, UTFSM
> Fedora Ambassador for Chile
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC proposal - GE Nodes

[Sven von Brand]

On 03/29/2011 11:24 PM, Mitchell Stokes wrote:
> Hello,
>
> Nodal Logic is a pretty big task. Mostly because of the all the design
> decisions to get it "right". I'm in the #blendercoders IRC channel
> (freenode) quite a bit using the nick Moguri. So, come find me if you
> want to chat. Also, I'd recommend talking with Campbell (Ideasman).

My idea was take what is somehow known to be needed and implement at 
least a functional node logic, if it only implemented what it's 
currently in the logic bricks it would already be a step forward, but 
I'll find you during the week to chat about it,

> Good luck!
>

thanks!

> --Mitchell Stokes (Moguri)

-- 
Sven von Brand
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC proposal - GE Nodes

[Dalai Felinto]

Hi Sven,
Benoit actually has some code done for that. It's not a lot, but if I
remember correctly it's already handling part of the ui and the
internal structure.

Mitchell had some complementary ideas on Nodal Logic too (and hand on
IRC) so it would be nice to talk to him too.

The way I see it is that if you can have the internal structure all
implemented, the ui and the python hook you wouldn't even need to
implement all the nodes. That's something that could come later with
time.

I'm glad you are interested on this project. Thumbs up.
Regards,
Dalai

2011/3/29 Sven von Brand :
> On 03/29/2011 11:24 PM, Mitchell Stokes wrote:
>> Hello,
>>
>> Nodal Logic is a pretty big task. Mostly because of the all the design
>> decisions to get it "right". I'm in the #blendercoders IRC channel
>> (freenode) quite a bit using the nick Moguri. So, come find me if you
>> want to chat. Also, I'd recommend talking with Campbell (Ideasman).
>
> My idea was take what is somehow known to be needed and implement at
> least a functional node logic, if it only implemented what it's
> currently in the logic bricks it would already be a step forward, but
> I'll find you during the week to chat about it,
>
>> Good luck!
>>
>
> thanks!
>
>> --Mitchell Stokes (Moguri)
>
> --
> Sven von Brand
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC proposal - GE Nodes

[Benoit Bolsee]

Hi Sven,

Thank you for your interest in the Node project.  The wiki page on the
GE node system is the result of design effort that I carried in 2009. It
was a difficult exercise because I had ambitious goals: I wanted to have
a generic, high performance, node engine that supports both push and
pull data flow and all types of program construct and allows to build
reusable node graphs. I didn't find a solution for all the issues but I
had enough to start working on the engine. It was going well but I was
dragged away by other work and never found the time and energy to get
back to it. You'll find the result of my efforts in the ge_nodelogic
branch (directory source/gameengine/NodeLogic). It's not much, not even
sufficient to be the necessary base of a new Node project, but it
exists. 

If you would decide to take it back and propose a GSoC project based on
that, I would be happy to be your mentor. And should the project be
accepted, I'm sure I would find the time to work in parallel on it. 

A fully integrated node system with GUI, GE binding, node library, etc,
is way outside the scope of a GSoC project, but I think that getting a
general purpose python node engine to work with the characteristics I
listed above is a facinating project. The integration with the GE
wouldn't even have to be done, as long as it's possible. Send me an
Email if you want to discuss about it.

Regards,
Benoit

Wed, 30 Mar 2011 09:38:56, Dalai Felinto 
> 
> Hi Sven,
> Benoit actually has some code done for that. It's not a lot, 
> but if I remember correctly it's already handling part of the 
> ui and the internal structure.
> 
> Mitchell had some complementary ideas on Nodal Logic too (and hand on
> IRC) so it would be nice to talk to him too.
> 
> The way I see it is that if you can have the internal 
> structure all implemented, the ui and the python hook you 
> wouldn't even need to implement all the nodes. That's 
> something that could come later with time.
> 
> I'm glad you are interested on this project. Thumbs up. Regards, Dalai
> 
> 2011/3/29 Sven von Brand :
> > On 03/29/2011 11:24 PM, Mitchell Stokes wrote:
> >> Hello,
> >>
> >> Nodal Logic is a pretty big task. Mostly because of the all the 
> >> design decisions to get it "right". I'm in the #blendercoders IRC 
> >> channel
> >> (freenode) quite a bit using the nick Moguri. So, come 
> find me if you
> >> want to chat. Also, I'd recommend talking with Campbell (Ideasman).
> >
> > My idea was take what is somehow known to be needed and 
> implement at 
> > least a functional node logic, if it only implemented what it's 
> > currently in the logic bricks it would already be a step 
> forward, but 
> > I'll find you during the week to chat about it,
> >
> >> Good luck!
> >>
> >
> > thanks!
> >
> >> --Mitchell Stokes (Moguri)
> >
> > --
> > Sven von Brand ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> 
> 


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC proposal - GE Nodes

[Sjoerd de Vries]

Hi Sven and all,

For the past year or so I have been quietly coding on a standalone,
pure-Python system for game logic nodes.
The code was finished this week. It is bundled with a standard library of
about 100 nodes, but this will probably grow a lot more.
It will be released in a few weeks, once I have finished some examples,
documentation and a screencast (thanks Ideasman for the suggestion!)

At the moment, it has bindings only to Panda3d, not yet to the BGE. It has
been developed under Ubuntu and not yet tested under any other platform.
Anyone who is interested in a sneak preview can email me for the source
code.

cheers

Sjoerd

Date: Thu, 31 Mar 2011 21:17:53 +0200
> From: "Benoit Bolsee" 
> Subject: Re: [Bf-committers] GSoC proposal - GE Nodes
> To: 
> Message-ID: <614B946E70A3455194463343836B7C11@Benoit95>
> Content-Type: text/plain;   charset="us-ascii"
>
> Hi Sven,
>
> Thank you for your interest in the Node project.  The wiki page on the
> GE node system is the result of design effort that I carried in 2009. It
> was a difficult exercise because I had ambitious goals: I wanted to have
> a generic, high performance, node engine that supports both push and
> pull data flow and all types of program construct and allows to build
> reusable node graphs. I didn't find a solution for all the issues but I
> had enough to start working on the engine. It was going well but I was
> dragged away by other work and never found the time and energy to get
> back to it. You'll find the result of my efforts in the ge_nodelogic
> branch (directory source/gameengine/NodeLogic). It's not much, not even
> sufficient to be the necessary base of a new Node project, but it
> exists.
>
> If you would decide to take it back and propose a GSoC project based on
> that, I would be happy to be your mentor. And should the project be
> accepted, I'm sure I would find the time to work in parallel on it.
>
> A fully integrated node system with GUI, GE binding, node library, etc,
> is way outside the scope of a GSoC project, but I think that getting a
> general purpose python node engine to work with the characteristics I
> listed above is a facinating project. The integration with the GE
> wouldn't even have to be done, as long as it's possible. Send me an
> Email if you want to discuss about it.
>
> Regards,
> Benoit
>
> Wed, 30 Mar 2011 09:38:56, Dalai Felinto 
> >
> > Hi Sven,
> > Benoit actually has some code done for that. It's not a lot,
> > but if I remember correctly it's already handling part of the
> > ui and the internal structure.
> >
> > Mitchell had some complementary ideas on Nodal Logic too (and hand on
> > IRC) so it would be nice to talk to him too.
> >
> > The way I see it is that if you can have the internal
> > structure all implemented, the ui and the python hook you
> > wouldn't even need to implement all the nodes. That's
> > something that could come later with time.
> >
> > I'm glad you are interested on this project. Thumbs up. Regards, Dalai
> >
> > 2011/3/29 Sven von Brand :
> > > On 03/29/2011 11:24 PM, Mitchell Stokes wrote:
> > >> Hello,
> > >>
> > >> Nodal Logic is a pretty big task. Mostly because of the all the
> > >> design decisions to get it "right". I'm in the #blendercoders IRC
> > >> channel
> > >> (freenode) quite a bit using the nick Moguri. So, come
> > find me if you
> > >> want to chat. Also, I'd recommend talking with Campbell (Ideasman).
> > >
> > > My idea was take what is somehow known to be needed and
> > implement at
> > > least a functional node logic, if it only implemented what it's
> > > currently in the logic bricks it would already be a step
> > forward, but
> > > I'll find you during the week to chat about it,
> > >
> > >> Good luck!
> > >>
> > >
> > > thanks!
> > >
> > >> --Mitchell Stokes (Moguri)
> > >
> > > --
> > > Sven von Brand ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC Proposal: Inferred Rendering (BGE)

[Daniel Stokes]

I would love to implement inferred rendering options in to the Blender Game
Engine (especially as deferred rendering becomes more and more common in
games and engines) as a Google Summer of Code project.

To this end, I would appreciate any feedback on my proposal:
http://wiki.blender.org/index.php/User:Kupoman/BGE_Render_Proposal

Thank you,
Daniel Stokes
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal: 360 video stabilization

[Péter Finta]

Hello Blender community,
I'm Péter Finta, a student applying for the summer of code.

I'm interested in working on motion tracking and stabilizing spherical/360
videos.

With the rise in popularity of virtual reality comes a rise in demand for
> VR content, much of which is in the form of spherical “360°” video. Such
> content can be captured with a consumer 360° camera; however, footage from
> such a device is often handheld or attached to a moving object, introducing
> additional motion making for a poor viewing experience, especially in VR
> where it cause severe motion sickness. This project intends to apply motion
> tracking to such footage, primarily for orientation stabilization, but also
> to solve for the three-dimensional displacement of the camera.
>

Here's my draft proposal:
https://docs.google.com/document/d/106OHEeExufJGX5LehUPjmQdqJXrvBxPErxXcLeUGhTs/edit?usp=sharing

I'd be interested in any feedback.

Many thanks,
- Péter
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC Proposal Draft: Outliner Improvements

[Nathan Craddock]

Hello everyone!

I've been writing my proposal for improving the outliner during the 
summer of code. I've made some tests in the source code which can be 
seen in the draft.


Here is a link to my draft:


I would love to hear some feedback on this!

Thank you,
Nathan Craddock

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: Inferred Rendering (BGE)

[Dalai Felinto]

Hello Daniel,
first of all I like your proposal, it seems like an interesting gsoc project.

The only thing I miss there is a short comparison (can be a table or
so) between the current bge render egine, inferred rendering and other
methods (e.g. deferred rendering).

Thanks,
Dalai

2011/4/2 Daniel Stokes :
> I would love to implement inferred rendering options in to the Blender Game
> Engine (especially as deferred rendering becomes more and more common in
> games and engines) as a Google Summer of Code project.
>
> To this end, I would appreciate any feedback on my proposal:
> http://wiki.blender.org/index.php/User:Kupoman/BGE_Render_Proposal
>
> Thank you,
> Daniel Stokes
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC proposal: 360 video stabilization

[Sybren A . Stüvel]

Hello Péter,

I don't see your proposal at the Google Summer of Code website. Did
you send in your final proposal there?

Regards,
Sybren

On Sun, Apr 02, 2017 at 10:45:17PM -0400, Péter Finta wrote:
> Hello Blender community,
> I'm Péter Finta, a student applying for the summer of code.
> 
> I'm interested in working on motion tracking and stabilizing spherical/360
> videos.
> 
> With the rise in popularity of virtual reality comes a rise in demand for
> > VR content, much of which is in the form of spherical “360°” video. Such
> > content can be captured with a consumer 360° camera; however, footage from
> > such a device is often handheld or attached to a moving object, introducing
> > additional motion making for a poor viewing experience, especially in VR
> > where it cause severe motion sickness. This project intends to apply motion
> > tracking to such footage, primarily for orientation stabilization, but also
> > to solve for the three-dimensional displacement of the camera.
> >
> 
> Here's my draft proposal:
> https://docs.google.com/document/d/106OHEeExufJGX5LehUPjmQdqJXrvBxPErxXcLeUGhTs/edit?usp=sharing
> 
> I'd be interested in any feedback.
> 
> Many thanks,
> - Péter
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: PGP signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC proposal: 360 video stabilization

[Ton Roosendaal]

Hi,

It's there, put on your glasses!

-Ton-


Ton Roosendaal  -  t...@blender.org   -   www.blender.org
Chairman Blender Foundation, Director Blender Institute
Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands



> On 04 Apr 2017, at 09:33, Sybren A. Stüvel  wrote:
> 
> Hello Péter,
> 
> I don't see your proposal at the Google Summer of Code website. Did
> you send in your final proposal there?
> 
> Regards,
> Sybren
> 
> On Sun, Apr 02, 2017 at 10:45:17PM -0400, Péter Finta wrote:
>> Hello Blender community,
>> I'm Péter Finta, a student applying for the summer of code.
>> 
>> I'm interested in working on motion tracking and stabilizing spherical/360
>> videos.
>> 
>> With the rise in popularity of virtual reality comes a rise in demand for
>>> VR content, much of which is in the form of spherical “360°” video. Such
>>> content can be captured with a consumer 360° camera; however, footage from
>>> such a device is often handheld or attached to a moving object, introducing
>>> additional motion making for a poor viewing experience, especially in VR
>>> where it cause severe motion sickness. This project intends to apply motion
>>> tracking to such footage, primarily for orientation stabilization, but also
>>> to solve for the three-dimensional displacement of the camera.
>>> 
>> 
>> Here's my draft proposal:
>> https://docs.google.com/document/d/106OHEeExufJGX5LehUPjmQdqJXrvBxPErxXcLeUGhTs/edit?usp=sharing
>> 
>> I'd be interested in any feedback.
>> 
>> Many thanks,
>> - Péter
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
> 
> -- 
> Sybren A. Stüvel
> 
> https://stuvelfoto.nl/
> https://stuvel.eu/
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC proposal: 360 video stabilization

[Sybren A . Stüvel]

Found it!

I can't comment on the proposal itself, but I'd love to see 360° video 
stabilisation in Blender :)

Sybren

On Tuesday, 4 April 2017 10:55:40 CEST Ton Roosendaal wrote:
> Hi,
> 
> It's there, put on your glasses!
> 
> -Ton-
> 
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
> 
> > On 04 Apr 2017, at 09:33, Sybren A. Stüvel  wrote:
> > 
> > Hello Péter,
> > 
> > I don't see your proposal at the Google Summer of Code website. Did
> > you send in your final proposal there?
> > 
> > Regards,
> > Sybren
> > 
> > On Sun, Apr 02, 2017 at 10:45:17PM -0400, Péter Finta wrote:
> >> Hello Blender community,
> >> I'm Péter Finta, a student applying for the summer of code.
> >> 
> >> I'm interested in working on motion tracking and stabilizing
> >> spherical/360
> >> videos.
> >> 
> >> With the rise in popularity of virtual reality comes a rise in demand for
> >> 
> >>> VR content, much of which is in the form of spherical “360°” video. Such
> >>> content can be captured with a consumer 360° camera; however, footage
> >>> from
> >>> such a device is often handheld or attached to a moving object,
> >>> introducing
> >>> additional motion making for a poor viewing experience, especially in VR
> >>> where it cause severe motion sickness. This project intends to apply
> >>> motion
> >>> tracking to such footage, primarily for orientation stabilization, but
> >>> also
> >>> to solve for the three-dimensional displacement of the camera.
> >> 
> >> Here's my draft proposal:
> >> https://docs.google.com/document/d/106OHEeExufJGX5LehUPjmQdqJXrvBxPErxXcL
> >> eUGhTs/edit?usp=sharing
> >> 
> >> I'd be interested in any feedback.
> >> 
> >> Many thanks,
> >> - Péter
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> https://lists.blender.org/mailman/listinfo/bf-committers
> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers


-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: This is a digitally signed message part.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal Draft: Outliner Improvements

[Brecht Van Lommel]

Regarding unifying viewport and outliner selection. The proposal seems to
focus on how to handle this visually in the outliner, but there are deeper
design issues to solve.

The objects in the 3D viewport are only a subset of everything that can be
selected in the outliner. Multiple outliners can also each have their own
selection state. How and after which operator exactly should the selections
synchronized? Does "deselect all" also affect non-object items in the
outliner? What about objects that are hidden or not part of the current the
scene? Will drag & drop objects between outliners continue to work?

I'm not expecting proposals to have all the answers for these, just to
understand that visualizing this in the outliner is only part of the
problem.

On Fri, Mar 29, 2019 at 3:25 AM Nathan Craddock 
wrote:

> Hello everyone!
>
> I've been writing my proposal for improving the outliner during the
> summer of code. I've made some tests in the source code which can be
> seen in the draft.
>
> Here is a link to my draft:
> <
> https://docs.google.com/document/d/14qREitiaSZnuZ2hie1JUwpFZ-f9hPGB752ImvEP6v7w/edit?usp=sharing
> >
>
> I would love to hear some feedback on this!
>
> Thank you,
> Nathan Craddock
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal for continued LANPR development.

[Wu Yiming]

Hey everyone!

I'm YimingWu, a Chinese student who participated last year's GSoC to 
integrate LANPR into Blender2.8. I'm back with another proposal on its 
continued development. In this year I would probably shift my focus more 
to code review and prepare LANPR for the master (if that is going to be 
possible).

Please check here for the draft: 
http://www.wellobserve.com/index.php?page=NPR/2019/index_en.md

Have a great day!

YimingWu

xp8...@outlook.com

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal Draft: Outliner Improvements

[Nathan Craddock]

Thanks for the feedback Brecht. Now that you mention it I realize I have
really only discussed the UI aspects of the proposal. I will expand my
proposal to address some of those design issues.

On Sun, Mar 31, 2019 at 11:50 AM Brecht Van Lommel <
brechtvanlom...@gmail.com> wrote:

> Regarding unifying viewport and outliner selection. The proposal seems to
> focus on how to handle this visually in the outliner, but there are deeper
> design issues to solve.
>
> The objects in the 3D viewport are only a subset of everything that can be
> selected in the outliner. Multiple outliners can also each have their own
> selection state. How and after which operator exactly should the selections
> synchronized? Does "deselect all" also affect non-object items in the
> outliner? What about objects that are hidden or not part of the current the
> scene? Will drag & drop objects between outliners continue to work?
>
> I'm not expecting proposals to have all the answers for these, just to
> understand that visualizing this in the outliner is only part of the
> problem.
>
> On Fri, Mar 29, 2019 at 3:25 AM Nathan Craddock 
> wrote:
>
> > Hello everyone!
> >
> > I've been writing my proposal for improving the outliner during the
> > summer of code. I've made some tests in the source code which can be
> > seen in the draft.
> >
> > Here is a link to my draft:
> > <
> >
> https://docs.google.com/document/d/14qREitiaSZnuZ2hie1JUwpFZ-f9hPGB752ImvEP6v7w/edit?usp=sharing
> > >
> >
> > I would love to hear some feedback on this!
> >
> > Thank you,
> > Nathan Craddock
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSOC proposal and mentor related queries

[Punya Aachman]

 My name is Punya Aachman, and I want to submit a proposal for GSOC 2019.
Since this is my first time taking part in GSOC, I have little experience
in creating a proposal. For the past month, I have been working on a
project but had no in-depth knowledge of how the GSOC program. Now, I am
certain that the project I am working on fulfills the requirements and can
be submitted to the organization, but I am not in contact of any developer
or mentor.
May I know if this is the right place to ask for GSOC related issues? If
yes, then kindly point me in the right direction so that I can get my
proposal verified (or at least get in contact with a mentor). If I am too
late for any kind of communication, then please let me know if it is
necessary for me to have a mentor before submitting the proposal.

Thank you

Regards,
- Punya Aachman
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSOC proposal: Automated seam calculation for meshes + proposal idea

[Ρυακιωτάκης Αντώνης]

Hi all! I have made a proposal

http://socghop.appspot.com/gsoc/proposal/review/google/gsoc2011/kalast/1

and I would like some feedback, especially on the usability improvements for
UV calculation part. I am also considering adding a proposal for speeding up
the image texture painting by using GPU OpenGL framebuffer objects. My
estimation is that in terms of time it should be a separate proposal. Do you
think it is a good-viable idea?

Thanks!
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSOC proposal: Automated seam calculation for meshes + proposal idea

[Ρυακιωτάκης Αντώνης]

Second last-minute proposal here

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/kalast/12002

Texture painting GPU acceleration.

Any feedback welcome!
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC Proposal: Security through the use of signing files from blender.

[Leif Andersen]

Thanks to the help of Jonathan Ferguson, I managed to write a proposal on
what I believe could potentially solve a large chunk of the issues with
Blender Security, and do it seamlessly too.  For  anyone who was interested
in this discussion, here is my proposal, what do you think of this solution?

http://leifandersen.net/2010/04/09/prototype-for-transparent-file-security-in-blender-through-the-use-of-embedded-key-signing/

~Leif Andersen

--
My first contribution to the blender community:
http://leifandersen.net/2010/03/23/good-feeling-my-first-slightly-major-open-source-contribution/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] GSoC proposal: Improve the I/O compatibility of COLLADA with other applications in the areas of geometry and skeletal structures

[Arystanbek Dyussenov]

Improve the I/O compatibility of COLLADA with other applications in the
areas of geometry and skeletal structures


Abstract


COLLADA is a file format for 3D data exchange. Blender uses COLLADA to
allow users exchange data with other applications.

COLLADA is a format with a very wide coverage of types of stored data. At
the same time, the same data can be presented in a variety of ways in this
format. Because the goal of this format is to be common data exchange
format for an arbitrary number of 3D applications, there are differences
between how the data is presented in this format and how it is presented in
Blender. The same is true for all other applications which support this
format.

These differences and the mentioned flexibility of the format require a lot
of effort from Blender developers to get the result from this format, which
will satisfy the users.

There are currently flaws in Blender COLLADA support.


Benefits to Blender
===

I want to fix complex bugs in COLLADA support and also restructure some
complicated places in the code this summer.


Deliverables



Project details
===

I want to fix bugs related to import from GoogleSketchup:

- http://projects.blender.org/tracker/index.php?func=detail&aid=30301
- http://projects.blender.org/tracker/index.php?func=detail&aid=27629

To fix them it is necessary to refine the support of instance_nodes in the
importer, add support of geometry of type LINES and add import of multiple
geometries grouped in a single node. The attached examples will help me
test the correctness of the changes.

Also I want to fix the bug:

- http://projects.blender.org/tracker/index.php?func=detail&aid=25754

To fix it, it will be necessary to add support of import of skinned meshes
linked with several skeletons without a common root. To do this, I think, I
will have to combine independent skeletons into one. Also this example will
help me to start realization of import of skeleton trees, containing
non-joint nodes. The example from the report will help me test the
functionality.

Also I want to fix this bug in the importer:
- http://projects.blender.org/tracker/index.php?func=detail&aid=28894

It is a complex scene from FloorPlanner which causes a crash.

I will try to fix this bug:
- http://projects.blender.org/tracker/index.php?func=detail&aid=28378

The problem in bone matrix interpretation.

Also I want to fix bugs in the exporter:

- http://projects.blender.org/tracker/index.php?func=detail&aid=27640

Add the possiblity of export of meshes, consisting of only points or points
and lines.

- http://projects.blender.org/tracker/index.php?func=detail&aid=24759

Add the possibility of export of a skeleton, to which multiple geometries
are attached.

Also, I want to try to fix other priortiy bugs from this list:
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Import_Export#Import:_Bugs

Besides these bugs, I want:

- to study and improve the situation with export of meshes with modifiers
- to export skeleton animation by default in the key-per-frame form for
more correct transfer of interpolations
- add a user option to export skeleton animation in non-key-per-frame mode.
This will allow a user to modify animation in other packages

Besides these changes, I want to improve the structure of the code to make
it more comprehensible for other developers. I want to review these
functions in the code:

- MeshImporter::create_mesh_object() - quite complicated code. I think it
is better to fix it now.
- AnimationImporter::translate_Animations() - make the function more
accessible.


Project schedule


TBD


-- 
Best regards,
Arystanbek Dyussenov
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers