[Bf-committers] Support for creases in subdivision surfaces
Thu, 17 Jun 2004 12:45:03 +0200
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?
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
> 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
> surfaces and one implementation (I guess the addition to blender could
> considered a second, but I really didn't change much, the
> that was there, is still all there. There are just some additional
> I want to help.
> I do not think my efforts so far are wasted, perhaps I have at least
> some ability and knowledge of the subject. I realize I jumped in with
> 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
> out my idea and submit it for comment.
> Thanks for the advice.
> 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
>> 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
>> 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
>> have made sure that their method follows certain important properties
>> are not necessarily going to be present in an ad-hoc implementation.
>> 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
>> 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
>> continuing to, avoid them.
>> --- Chris McFarlen <email@example.com> wrote:
>>> (Umm... I sent this from the wrong account and the moderator grabbed
>>> it. Sorry if it shows up
>>> 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
>>> conference proceedings. The implementation I settled on for my
>>> research used the binary
>>> 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
>>> 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
>>> 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
>>> 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
>>> 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.
>>> 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
>>>> 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.
>>>>> edge is either sharp, or it isn't. This isn't as much of a
>>>>> 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;
>>>> 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
>>>> off level) would allow you to implement weight factors. Let's say
>>>> 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
>>>> shift the bits right, to
>>>> bit 31 -> 0000 0000 0000 0000 0000 0000 0000 0111 <-bit 0 (the
>>>> 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
>>>> 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.
>>>> Bf-committers mailing list
>>> Bf-committers mailing list
>> daniel dunbar
>> Bf-committers mailing list
> Bf-committers mailing list
Ton Roosendaal Blender Foundation firstname.lastname@example.org