[Soc-2014-dev] Weekly Report #13: NURBS Modernization

[Sergey Sharybin]

Answers are inlined


On Wed, Aug 20, 2014 at 12:30 AM, Jonathan deWerd <jjoonathan at gmail.com>
wrote:

> On Aug 19, 2014, at 5:30 AM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>
> I'm not really sure why you spent time on adding some new functionality
> (which is not even documented and in the really questionable way) at the
> last coding week instead of making sure someone can actually test your work.
>
> - What is the whole point of the NURBS UV editor? And when this raised in
> the project?
>
> I added the new functionality to make sure people could test my work. Both
> you and Ton were surprised and displeased when you found that the only way
> to get trims in Blender was to import a Rhino file. We never made specific
> plans for how to edit trims in blender but you said (and I agreed) that not
> being able to do this was "very bad" -- so I dropped what I was doing and
> prioritized the feature that allowed users to define and edit trims in
> Blender.
>

Yes, improving blender itself is much more priority than supporting more
formats, especially if you need to improve blender in order to make import
to work.

But that doesn't mean you couldn't have shared some imported .blend files
which demonstrates the progress.

It would be nice to have the ability to define and edit trims from the 3D
> viewer. I sketched out several possible strategies to do this, but they all
> required nontrivial math that would have taken too long to get working
> well. The UV Editor is the "minimum viable product" and even so it barely
> managed to arrive on time. Since the UV Editor is needed both in the big
> picture (texturing NURBS, editing tessellations, aligning supersurfaces)
> and in the little picture (I need in-blender trim editing to show off my
> work) I still think it was a good move. But regardless of whether it was
> "good," it was necessary.
>

Texturing NURBS is rather a huge project on it's own. It'll touch all the
areas starting from the viewport shading ending with making blender
renderer and Cycles work with the textured NURBS (currently they only
supports generated coordinates). This could be considered into account when
making decision about editing trims, but it's rather well separated project.

And the thing here is, after doing the sketches you shouldn't have making
final decision on your own, but discuss with the mentor at least, making
sure all this fits nicely into the pipeline. Plus in such a things artists
feedback is really important before doing decisions on how the edit
pipeline will work.

Adding such a functionality (and even planning to add more stuff) to the
Image/UV editor sounds just wrong. But what's done is done. Just before
continuing working in there get the artists feedback.


> Sample .blend files were requested ages ago, but the whole work is still
> remains a mystery (apart from some screenshots in the wiki which are not so
> much informative).
>
> I put a sample .blend file in the wiki last week and importable Rhino
> files since ~midterm time.
>
> http://wiki.blender.org/index.php/User:Jjoonathan/NURBS_UVEdit  search
> for "Sample_trimmed_nurbs.blend"
>

Cool, raises the tip of the day i bet: link might easily be lost inbetween
of loads of images..


> - C90 is still not met, you've got loads of cases when you mix code and
> declarations. Here's the patch for you http://www.pasteall.org/53523/diff
> (and hey, most of the stuff i already sent to you like 2 weeks ago)
> - This is tuesday already, and there's still C++11 existing in the code
> (c'mon, it takes 3min to zap it), also there's still no final summary page.
>
> Thanks for the patch. The holdup on my end is not fixing the nonconforming
> C90 and C++11 bits, it's finding them in such a way that I know I have
> found all of them. I have put a total of ~2 working days into this task.
> Clang's dialect options (e.g. "-ansi", "-std=c89", "-std=gnu89",
> "-std=c90", etc) seem to be too strict to compile at all (errors everywhere
> in blender), too lenient to catch the nonconforming bits, or put out so
> many warnings that the interesting nonconforming bits are very difficult to
> find in millions of "extra semicolon", "comma at end of enum", etc warnings
> (officially those are C99 features?). It is a nontrivial task to use GCC
> because Xcode doesn't seem to support it and CMake seems to require
> tweaking to discover the 3rd party GCC installs even for "Unix Makefile"
> builds (and then gcc complains about the libraries in ../lib). I set up
> VS2013 on a Windows computer as an alternative but now the computer doesn't
> boot (and "automatic repair", whatever that's supposed to do, doesn't work)
> :/
>
> I did manage to get Clang to emit useful errors for C89 violations. I have
> not managed to get it to emit useful C++98 violations. If I can't get it
> working in a few hours I'll try the buildbots.
>

Again, you shouldn't have wasted time on this, but ask folks around in IRC.
We've got quite reasonable amount of devs who uses windows and don't have
issues detecting C90 violations. My best guess would be that installing
mingw is rather really easy and it'll compile minimal subset of blender
(you don't need osl and such) making you able to find the issues. Also bet
msvc could be configured in the way that will at least generate the warning
when mixing code and declarations.


> - It's too early to prepare patch for the review, the branch is to be
> cleaned up.
>
> Yes. Now that the NURBS UV Editor ("Trim Editor"?) has reached
> minimum-viable-product status I will focus on cleanup.
>

Wrapping trim editing is for sure crucial, also requires loads of user
feedback. There are also quite a few of other things to be cleaned up but
those are better to be discussed after all the stuff for the evaluatio nare
done.


> Things to be done ASAP:
> - Make sure your branch compiles for average artist (my bet is that the
> proposed patch makes it compilable, but it might be some extra things
> required)
>
> I assume this means "builds on Windows/Linux with gcc". I'll grab some
> virtual machines and see what I can do. While those are building, I'll try
> the buildbot.
>

With the patch i've provided it should all work. No need to do virtual
machines, linux i've tested. Windows seems you know that it works. For OSX
you can poke someone in IRC. (and yeah, hope you got it -- development is
not only about sitting in the cave and coding, but also communicating in
IRC).


> - Write the final documentation, making sure artists can follow it and see
> the benefits
>
> In progress.
>

Cool. Make it really good documentation, with all the information needed
for both artists and developers. Don't worry about the code yet, better to
be around after the evaluation (which is really cool when GSoC student
sticks around after the program is over). Then you'll have enough time to
clean all the stuff up making it an ultimate patch.


> - Prepare sample .blend files which demonstrates the new functionality
> (which keeps being requested since weeks ago!)
>
> It has been done since weeks ago :P
>

Alright, got it. Would check in details tomorrow.


-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2014-dev/attachments/20140820/023a69ad/attachment.htm