「Dev:Source/Modeling/CCGSubSurf」の版間の差分

提供: wiki
移動先: 案内検索
(Bot: Fixing redirects)
 
(1版 をインポートしました)
 
(相違点なし)

2018年6月29日 (金) 02:45時点における最新版

CCGSubSurf

The CCGSubSurf library is a new implementation of Catmull-Clark subdivision surfaces that I have been working on and refining for a very long time. At some point in the near future it will get a webpage of its own (I plan to release it into public domain).

Compared to the existing blender implementation the CCGSubSurf implementation is much more tuned for performance. At high subdivision levels it is faster and consumes significantly less memory. It is also incremental which means that during editing it supports only rebuilding the parts of the mesh that have changed.


Todo and Future Work

UVs and Vertex Colors

The tricky part with UVs and vertex colors is making them work when they are not shared across the mesh. That is, in cases where you have two adjacent faces but their UV coordinates aren't shared. This means the way the geometry is subdivided is different from how the UVs are subdivided, and adds a lot of complexity.

I tried to solve this once in the past and it just turned out way too complicated and I gave up, instead planning on using a multi-pass scheme where geometry would be done in one subsurf call and UVs in another. Today (Mar 23 2005) I think I saw how to integrate it into the CCGSubSurf library without actually adding too much complexity (or sacrificing speed). This would be part of a general CCGSubSurf release.

In fact, in Blender at the moment shared UV or vertex color information does not exist (not quite true, you can have shared vertex colors, but then they have to be shared everywhere). The information can be inferred to some extent by just comparing two adjacent UV coords and if they are identical (or nearly so) assuming they are shared. However, it would be nice anyway if this information became explicit - mostly just for the user interface it would be nice to be able to define UV coords or vertex colors to be shared in certain regions.

Creasing

In the more long-term future I am hoping to implement proper creasing, more mathematically well-defined than the current ad-hoc implementation copied from Blender. This will be part of a general CCGSubSurf release. My plan is to implement (possibly a subset) of "Piecewise Smooth Subdivision Surfaces with Normal Control" by Biermann et al, see: http://mrl.nyu.edu/publications/piecewise-smooth/

Actually using this new style creasing would require user interface work in blender, as the creasing parameters on the mesh are more complicated than the current edge crease parameter.

More Fun Stuff

I will probably extend the CCGSubSurf lib to support computing the subdivision surface iteratively (not a good word choice, but I didn't want to reuse incremental). This would enable a couple nice user interface features: (1) Subdivision calculation could be escaped and progress displayed, (2) it would be possible to display levels of the subdivision as they were calculated. If a bit of work was put into it this could make for a very highly interactive editing process where during an interactive edit the subdivision would start and would display levels as soon as they were done - as soon as the user moved the mouse the old subdivision calculation would cancel and a new one would start. This would get rid of need for a separate "interactive" display subdivision level.

Comments

Nice to see you have proper UV subdivision planned. It was on my Todo list, but I got stuck figuring out what to do on edges where the UVs are not shared, and I didn't dig much deeper.

About explicit sharedness of UVs, that doesn't seem like a good idea. I've considered this in the past, but eventually decided it was better to use implicit sharedness, and let the tools that need to know sharedness detect it. In my opinion, explicit sharing will mostly add more work for the user, to manage this information, and keep adjusting it while working on the UV map. It could also add confusion, since this sharedness data is quite abstract, it's not something you see by glancing at the UV map, leading to unexpected results for users. Although it's not very nice from a coder's point of view to be comparing UV distances, I think it's clear and simple from the user side. -- Blenderwiki.BrechtVanLommel#27Mar105 BVL

-- DanielDunbar - 21 Mar 2005