[Bf-committers] Support for creases in subdivision surfaces

Ton Roosendaal bf-committers@blender.org
Thu, 17 Jun 2004 12:45:03 +0200


Hi Chris,

I was wondering what the status is of this feature... I see cool things  
already being modeled with it in Tuhopuu, so maybe it's time to think  
over the migration to bf-blender for it.
Are you ever on irc to discuss it? Shall we do it here?

-Ton-


On Friday, May 7, 2004, at 20:44 Europe/Amsterdam, Chris McFarlen wrote:

> This is a good point.  I would like to be a part of the Blender  
> development
> community, so I don't want to be rash and jump into an implementation
> that is going to cause problems.  I have read several papers on  
> subdivision
> surfaces and one implementation (I guess the addition to blender could  
> be
> considered a second, but I really didn't change much, the  
> implementation
> that was there, is still all there.  There are just some additional  
> rules).
> I want to help.
>
> I do not think my efforts so far are wasted, perhaps I have at least  
> shown
> some ability and knowledge of the subject.  I realize I jumped in with  
> both
> feet and kept right on running, but I was excited to be able to add
> something to Blender and see the community react favorably.
>
> I will do more research and talk with others who have shown interest in
> this feature.  Maybe we can come up with something that looks like a
> formal design on the feature and go from there.  I can at least fully  
> write
> out my idea and submit it for comment.
>
> Thanks for the advice.
>
> Chris
>
> On Friday 07 May 2004 12:39, Daniel Dunbar wrote:
>> I think it is reasonably important that the creasing implementation
>> of Blender follow an established method. There are two primary  
>> candidates
>> in my opinion, the first is to follow the method that is used for the
>> AQSIS open source renderer... as this is the only important open  
>> source
>> implementation of creasing for catmull clark subdivision surfaces I am
>> aware of I think it would be a reasonable role to set to follow their
>> implementation. (There is also a modeller that follows the AQSIS
>> convention, I forget the name).
>>
>> On the other hand Biermann et al. have established a method that seems
>> to have become standard in the CC literature for creasing, and  
>> additionally
>> have made sure that their method follows certain important properties  
>> that
>> are not necessarily going to be present in an ad-hoc implementation.
>> See:
>> http://www.mrl.nyu.edu/publications/piecewise-smooth/
>>
>> I have not researched creasing very much, but I would dislike to see
>> a precedent for creasing set that will be annoying to follow if the
>> subdivision code is replaced. In particular I would prefer to follow
>> established research, in order that we are well positioned to take
>> advantage of subsequent research.
>>
>> I have not had time to review your patch, but I am curious as to
>> how you encode edge based data in faces. I hope it is done in a
>> manner so that no ambiguities would exist were a proper edge structure
>> to be implemented (I imagine it is already, but it is something to  
>> keep
>> in mind).
>>
>> One note: C bitfields while convient, have disadvantages and are not
>> the most cross platform of constructs. We have tended to, and I  
>> recommend
>> continuing to, avoid them.
>>
>> --- Chris McFarlen <chris@mcfarlen.us> wrote:
>>> (Umm... I sent this from the wrong account and the moderator grabbed  
>>> it.  Sorry if it shows up
>>> twice)
>>>
>>> I didn't know anyone was working on this :)  When I started looking  
>>> (on Sunday) the blender.org
>>> page was slashdotted
>>> so I didn't know about the mailing list.  I asked the guys on  
>>> #blendercoders and they said "Go
>>> for it!".  So I did.  Sorry.
>>>
>>> I have been convinced the weights should be there.  I have Pixar's  
>>> white paper on their surfaces
>>> used for
>>> creating Geri from 'Geri's Game' (The old guy playing chess with  
>>> himself).  It is in the 1998
>>> SIGGRAPH
>>> conference proceedings.  The implementation I settled on for my  
>>> research used the binary
>>> sharp-or-not
>>> method (I forget who pioneered this one, don't have the bibliography  
>>> in my research, but is
>>> certainly not Pixar's approach)
>>>  but I did not consider the limitation of not having a smoothing  
>>> weight a big problem
>>> (you can use more edges to approximate this, I thought...).  The  
>>> problem is, I never built a
>>> reasonable control mesh editor
>>>  to test my theory about the limitation.  Since adding my crease  
>>> implementation to blender
>>> (which
>>> has a great editor), I am convinced I was wrong.  Its hard to create  
>>> a sharp to smooth
>>> transition along
>>> one path using just a binary flag.
>>>
>>> So, I'm going to go right into adding the weight factors.  I propose  
>>> this:
>>>
>>> Each edge in the control mesh has 2 weights, one for each vertex.   
>>> The weights have the
>>> following meanings:
>>>
>>> 0 - no sharpness, smooth
>>> (0..1) - interpolated sharpness
>>> [1..inf) - infinitely sharp
>>>
>>> When dividing an edge, the weight used is determined by w = (w1 +  
>>> (w2-w1)/2), then:
>>>
>>> if w is very close to 0 use smooth rule for new edge point
>>> if w >= 1 use sharp rule for the new edge point
>>> else
>>>   new edge point = (smooth rule point) + w*((sharp rule point) -  
>>> (smooth rule point))  (a vector
>>> equation, the point is somewhere in between the smooth and sharp  
>>> point)
>>>
>>> You then assign w to the weights of all edges attached to this new  
>>> vertex to feed back into the
>>> next division.
>>>
>>> With this method, if both weights of an edge are equal and >= 1, the  
>>> effect is the same as sharp
>>> (as you get now).
>>> If the weight is 0 on one end and 1 on the other, the edge goes from  
>>> completely smooth to
>>> completely sharp. You can
>>> make an edge be sharp longer by having the sharp edge > 1.  So if  
>>> the weights were 0 and 2, then
>>> half of the edge
>>> would be completely sharp, and half transition from completely  
>>> smooth to sharp.
>>>
>>> Based on the changes I made for binary creases, I should be able to  
>>> demonstrate this fairly
>>> quickly.  I don't want
>>> to step on any toes, so if anyone has a problem with me continuing,  
>>> let me know.
>>>
>>> Later,
>>> Chris
>>>
>>> On Friday 07 May 2004 11:28, Matthew H. Plough wrote:
>>>> Chris McFarlen wrote:
>>>>
>>>>> I added support for creases in the Catmull-Clark subdivision  
>>>>> surfaces.  You can read about it
>>> and download the patch here:
>>>>>
>>>> Well Chris, congratulations!  You have officially scooped the work  
>>>> that
>>>> I was planning to do!  This is an excellent addition to Blender, and
>>>> should greatly increase the capabilities of subdivision surfaces.
>>>>
>>>> Chris McFarlen's website wrote:
>>>>
>>>>> I extended the blender implementation to include creases, but my
>>>>> implementation only defines a binary sharpness; no weight factors.  
>>>>> An
>>>>> edge is either sharp, or it isn't. This isn't as much of a  
>>>>> limitation
>>>>> as it might seem. No, really :)
>>>>
>>>> This really is a limitation, and one that shouldn't be there.  The
>>>> implementation that I had been working on includes weight factors;  
>>>> they
>>>> are relatively easy to implement.  You are using a flag to set the
>>>> subdivision level; seeing as Blender only subdivides out to level 6,
>>>> using three bits (for a total of seven possible levels, as well as  
>>>> an
>>>> off level) would allow you to implement weight factors.  Let's say  
>>>> that
>>>> those are bits 31, 30, and 29 of a standard int.
>>>>
>>>> (1) bit 31 -> 111* **** **** **** **** **** **** **** <-bit 0 would
>>>> indicate an infinite crease edge,
>>>> (2) bit 31 -> 000* **** **** **** **** **** **** **** <-bit 0 would
>>>> indicate a normal edge, and
>>>> (3) bit 31 -> 010* **** **** **** **** **** **** **** <-bit 0 would
>>>> indicate an edge with sharp subdivision level 2.
>>>>
>>>> Since endian-ness is not an issue at runtime, it is a simple matter  
>>>> to
>>>> shift the bits right, to
>>>>
>>>> bit 31 -> 0000 0000 0000 0000 0000 0000 0000 0111 <-bit 0 (the  
>>>> result
>>>> for an infinite crease edge)
>>>>
>>>> Now, if the result is 0, then a smooth subdivision should be used.
>>>> Otherwise, use a sharp subdivision, and decrement.  Then, shift the
>>>> result back to
>>>>
>>>> bit 31 -> 0010 0000 0000 0000 0000 0000 0000 0111 <-bit 0 (the  
>>>> result
>>>> for a decremented (3), above)
>>>>
>>>> and bitwise OR it into the flag integer for the resulting edge.
>>>>
>>>> I hope this is clear -- if not, say so, and I will try to explain  
>>>> it better.
>>>>
>>>> Matt
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers@blender.org
>>>> http://www.blender.org/mailman/listinfo/bf-committers
>>>>
>>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://www.blender.org/mailman/listinfo/bf-committers
>>
>>
>> =====
>> daniel dunbar
>> daniel@zuster.org
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://www.blender.org/mailman/listinfo/bf-committers
>>
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org