PDA

View Full Version : question on APS per-polygon-level with weight maps



sampei
03-06-2011, 01:11 PM
basically I want to have a subd level of 0 on the polys vmapped at -100 (blue) and a subd level of 50 on the polys vmapped at 100 (orange).
I've set up the gradient with 2 keys (step falloff).
After setting the first key's value at 0 on the ramp, I create a second key, place it at parameter 95 and start adding increments of 5 in the its value.
After a value (subd level) of 15 for the second key, the first key (for the blue polys) is overridden and the the "blue polys" start to be subdivived more than that stated by the gradient's first key. Why ?

I've found a couple of informative threads on APS:

http://www.newtek.com/forums/showthread.php?t=103407&highlight=aps+polygon

http://www.newtek.com/forums/showthread.php?t=53302&highlight=aps+polygon

sampei
03-07-2011, 07:02 PM
I might have found my anwere here: http://www.newtek.com/forums/showthread.php?t=59774&highlight=aps+weight
I'll do some tests with CC and see how it behaves.

sampei
03-07-2011, 09:57 PM
here's the quick tests, an interesting thing I just noticed with CC is that weight maps don't bleed from one poly to another.
Within the gradient, when operating the subd level via the key's value, only integers are valid (scalars will be floored before and including .4 and ceiled after).
From the tests I concluded that the aps operates the same way with both subdivision alghorims, but because of CC's algorithm refinement scheme the differences from one level of subdivision to the next is much greater than in sp, it's beneficial to use it with APS whenever major disparities in the density are desired, with the reminder that the catmull-clark/regulars subpatches ratio starts at 4 : 1 for level 1 but starts growing after and including level 3 , hence to obtain similar densities cc will always be a level before sp.
just a reminder between the differences between the 2 algorithms, from a post by Surrealist:


Simplified, here is how it works (you can covert you standard math formulas if you like):

In layout:

(Sample is 1 square polygon)

Subpatch: A level of 1 subdivides each polygon with one polygon. That is, it is a 1x1 subdivision = 1 polygon.

Then each polygon is converted into tris making 2 polygons. (The one polygon cut at a diagonal)

So level 1 = 2 polygons.

Level 2 is 2X2 subdivision = 4 polygons

Thats basically a row of 2 polygons down the X and a row of 2 polys up the Y.

Now these polys are divided diagonally to make tris = 8 polygons.

So level 2 = 8 polygons.

Level 3 is 3x3 subdivision = 9 polys made into tris (doubled) = 18 polys.

level 4 is 4x4 = 16 polygons, tris = 32 and so on.

Catmull Clark:

level 1

level one takes the original polygon (1) and doubles this number to come up with the number for (a)x(a) equation.

So it is 2x2 = 4 polys divided into tris to make 8 total polys

level 2

Takes the number created by level 1 (2) and doubles it so it is 4x4 = 16 doubled by making it into tris = 32

Numbers sounding familiar? Just like binary code for computer data and computation - well no need to go into that.

Level 3 takes the number from level 2 (4) and doubles that so it is 8x8 to get 64 subdivied into tris to get 128.

Then continuing, level 4 is 16x16 = 256 and made into tris = 512 polys

Level 4 Subpatch : 32 polys

level 4 CC : 512 ploys

And for Pixels Per Polygon calculation is a lot closer - by my tests. Sub patch is less polys but not by as much as the per object setting but it is close and the difference is how much of the object takes up the frame and the setting with smaller numbers being more polys.

Finally I was curious of trying an image map as alternate method of driving the per-polygon aps, so I UV mapped the same central polygon (previously vmapped at 100) and slapped a white solid bitmap on top, loading it in the aps texture editor under the same gradient wich i.p. was then set to previous layer. Seems like with this solution we are able to isolate further the subdivision, if you take a look at catmull-clark's level 5, the density of the mapped poly's neighborings is inferior to the weight mapped solution, this is also true for regular subpatches. The result is that the displacement is still present in the parts of mesh we choose via the image map, and the "leaks" are more contained, hence the poly count goes down (which was my initial goal). Not having done any more tests I can only speculate on the advantages that a map with multiple shades of gray might implicate, but since white seems to be the strongest value and black has no effect, and since that we already had soft transitions with weight maps I don't see any useful outlet for this (yet!).


http://img856.imageshack.us/img856/9240/comparisoncopy.png