[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