[Soc-2008-dev] Week 11 report

Nicholas Bishop nicholasbishop at gmail.com
Sat Aug 9 07:42:43 CEST 2008


Thanks, I'll take a look at that.

-Nicholas

On Sat, Aug 9, 2008 at 1:33 AM, joe <joeedh at gmail.com> wrote:
> You could try taking a look at the old HyperMesh subsurf code we used to
> have.  It's what was used before CCGSubSurf.  And since the customdata
> interpolation is done *outside* the CCGSubSurf code anyway, porting that
> should be no problem, to whatever code you end up using.
>
> The old code supports everything the new one does, except partial updating
> (of course, that's why CCGSubSurf was written in the first place).  And it's
> a lot simpler.
>
> You can see the code at:
>
> http://projects.blender.org/plugins/scmsvn/viewcvs.php/trunk/blender/source/blender/blenkernel/intern/subsurf.c?revision=4187&root=bf-blender&view=markup&pathrev=4187
>
> Joe
>
> On Fri, Aug 8, 2008 at 8:36 PM, Nicholas Bishop <nicholasbishop at gmail.com>
> wrote:
>>
>> a) Previous week:
>> * Fixed sculpt mode's partial redraw mode when used with multires
>> * Some speed improvements (less updating when it's known that
>> displacements haven't changed)
>> * Some bug fixes
>>
>> I also spent some time looking at speed and data structure issues. As
>> I explained last week, there are speed issues with the way level
>> updates and subdivision are currently handled. I've been experimenting
>> with some pretty radical changes, such as directly subdividing
>> displacements (rather than vertex coordinates) and also faster regular
>> subdivision of the mesh. Part of the problem is that CCGSubsurf was
>> designed for a different use than what multires is using it for. Its
>> partial-update system (used to good effect by the subsurf modifier in
>> editmode) is actually not of much to the multires modifier.
>> Speed-wise, CCGSubsurf is slower than an iterative subdivision
>> approach, and requires a lot of memory if applied to a dense base mesh
>> (this claim is based on comparing the old multires in trunk to the
>> subsurf modifier.) Based on this, I'm tentatively planning to write
>> new subsurf code. This will have to wait until after GSoC, of course.
>> The old multires subdivision code was a fairly basic Catmull-Clark
>> implementation, and as it noted above, it is fast. However, it had
>> some serious problems, notably in it's handling of customdata (and
>> especially UVs), and it's vertex ordering would be seriously
>> inconvenient to map displacements to. So something entirely new is
>> needed; I'll be looking into this more after the 18th.
>>
>> b) Next week:
>> Next week is the last week of GSoC. My top priority is fixing file
>> loading for old files. I've been trying to make progress with the
>> conversion, but the data storage is very different between the two
>> formats, and I'm having difficulty wrapping my brain around the best
>> approach (or really, any approach.) There's also a data-loss bug in
>> the file save code that needs to be fixed.
>>
>> On Fri, Aug 8, 2008 at 6:13 PM, Ian Thompson <quornian at googlemail.com>
>> wrote:
>> > Week 11 Report
>> > ==============
>> >
>> > This Week
>> > ---------
>> > The marker system is now in place. The behaviour of markers is dictated
>> > by their
>> > flags and groupings. Placing markers with the TMARK_EDITALL flag set
>> > allows a
>> > number of spans to be edited from one (as in the Find All case). The
>> > TMARK_TEMP
>> > flag denotes markers which should be removed once focus is taken
>> > elsewhere.
>> > Together with grouping information (currently the upper two bytes of a
>> > marker's
>> > flags) these provide a platform for code templates.
>> >
>> > The textplugin_templates.py contains an implementation of such a system,
>> > which
>> > may be extended by the user with a simple syntax (to be documented).
>> >
>> > Find all is implemented as an option ("Mark All") on the find and
>> > replace panel,
>> > which has also seen some improvements this week. It makes use of markers
>> > to edit
>> > all occurrences at once.
>> >
>> > The last few word-wrap functions (Home, End, etc.) have also now been
>> > completed.
>> >
>> > Next Week
>> > ---------
>> > Obtain as much feedback as possible. Solve any remaining issues and
>> > adjust any
>> > behaviour that may confuse or hinder users. Finish writing integration
>> > docs and
>> > write full user documentation ready for the wiki.
>> >
>> > Issues
>> > ------
>> > None
>> >
>> > Schedule
>> > --------
>> > The main code is complete. Time now to polish things off and get ready
>> > for
>> > integration. This is the final week and I'm on target to finish by the
>> > deadline.
>> > _______________________________________________
>> > Soc-2008-dev mailing list
>> > Soc-2008-dev at blender.org
>> > http://lists.blender.org/mailman/listinfo/soc-2008-dev
>> >
>> _______________________________________________
>> Soc-2008-dev mailing list
>> Soc-2008-dev at blender.org
>> http://lists.blender.org/mailman/listinfo/soc-2008-dev
>
>
> _______________________________________________
> Soc-2008-dev mailing list
> Soc-2008-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2008-dev
>
>


More information about the Soc-2008-dev mailing list