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