[Soc-2008-dev] Week 11 report

joe joeedh at gmail.com
Sat Aug 9 07:33:48 CEST 2008

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:



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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2008-dev/attachments/20080808/3718912a/attachment-0001.htm 

More information about the Soc-2008-dev mailing list