View Full Version : APS Question

11-28-2006, 02:13 PM
I been trying out APS with some success. I've used both weight maps and even images to control the amount of subdivision ... the only problem for me is that the difference between the amounts of subdivision isn't as high as I'd like. For instance, if I want a few patches on a sub-d model to be 10x as dense as the least divided areas, I'm out of luck. This often results in areas that don't need mesh density being too dense. When I use the methods shown in Proton's videos, they do work, but not to the extent I'd like. If I can avoid as much unnecessary mesh density as possible, it would help.

Not to bring up competing software, but I've done similar work in Maya/Mental Ray that can have a much greater difference between high and low mesh density at render time. I'm guessing that it has to do with Maya/MR using Micropoly displacement whereas LW does not. (Yet?)

I'm hoping that maybe someone has tried something in LW with APS that works better?


Thanks in advance!

11-28-2006, 05:08 PM
Theres definately rules that deal with how APS subdivides. I just finished a 4 hour video on APS and cover those rules in depth.

11-28-2006, 05:46 PM
In my case I have a model consisting of about 2,000 patches. I want to put displacement detail into some of the patches, but with only a 'moderate' amount of relief. In ten of the patches, I need to concentrate some comb-like spikes, almost like very coarse hair. Proton did some stuff like this in one of the Quicktimes on NewTek's site, but what I'm doing would need fewer but much thicker 'hairs.'

One big factor for me is that most of this work and the rendering will be done on a PC with as much ram as Win32 can deal with. So I'm working with the "2 gig per app" limit. (I may also use the 3 gig Switch which I have used successfully with LW)
If there is a way to work with what I've got, that would be great. Hopefully your materials will offer some insight. As a last resort I could buy a new 64 bit XP capable PC and more ram and solve the problem with brute force, but I'd like to avoid that expense.

Thanks for the link, I'll check it out.

11-28-2006, 08:49 PM
About greater control of subdivision density with APS I think you are out of luck!

To my experience (aswell) APS is simply not able to go from a very low density to a very high density in a short amount of distance, or I should say - short amount of patches! Because it seems to me it can only make one shift in subd level per patch. Or put differently and perhaps more correctly, a patch can't be more than one subd level higher or lower than it's neighbour(s).

So if you have 4 patches in a row you will only ever be able to achieve at most 4 different subdivision levels. And the lowest subdivision level will never be more than 4 levels behind the highest level. You can conclude than that the higher the density in the underlying mesh the more levels APS will eb able to achieve. Perhaps a good thing to know in some cases but it still doesn't give you very much more control and the rendered mesh will probably be overall more dense than you might like. APS is simply constrained by it's inability to shift more than one level per patch and by the structure of the underlying the mesh.

See attached image. Note how only one shift in level occurs at every patch and that the lowest level is no more than 4 steps behind the highest. I have been unable to brake this limit (in the few tests I did). Also interesting to note (if you like details) is how the shift only occurs at the edges of each patch.

I don't believe any video in the world could change this fact, not even one of Splinegods. (unless I'm horribly wrong that is. Which is always a possibility.)

Hopefully we'll see some alternative APS algortihms added in the future. Perhaps we could/should drag Jarno (or someone else from TuffLittleUnit) into this discussion to get a confirmation and perhaps a hint of what might be coming in the future? He seems to be very straightforward and generous with information.

11-28-2006, 08:57 PM
Hehe, I take it all back. Almost. I just tried CC subds and had better luck. It seems to be alittle bit more adaptive. I guess thanks to the subd algorithm working quite differently from LWs subpatches.

11-28-2006, 09:08 PM
Just for sake of completeness, here's the same mesh with same settings, but as CC subds. Looks much sweeter!

11-28-2006, 09:22 PM
The way CCs and SubDs subdivide are very different. Theres only one subpatch level where you get the same # of polys.Otherwise CCs subdivide much higher at the same subpatch level. :)

11-29-2006, 01:17 PM
Haven't really tried out CC Sub-Ds yet. I've heard some grumbling about issues surrounding CCs with slowness and stability, so I avoided them so far. Incidentally, the model I'm working with is all quads ... would I get any benefit in that case?

11-29-2006, 01:28 PM
It might benefit because CC subpatch levels produce polys differently then standard subpatches. :)
Some of the slowness of CCs is due to the fact that the subpatch levels produce more polys then standard subpatches.

11-30-2006, 11:21 AM
but as CC subds. Looks much sweeter!
As you can see, standard subD levels are linear. That is, the level number is the number of subdivision "row & colums". However, CC subDs do it by powers of 2. Each level cuts patches/polys in half.

So, looking at the two pix, stand. subD shows four levels, 1, 2, 3, and 4 with 1 poly divided into 2, then the same being cut into 3, and finally being cut into 4 (not counting the other direction of division). CC shows the the same 4 levels but instead the initial poly/patch is cut in half, then the next is split into four, the next divided into 8 and the last into 16 (not counting the other direction of division).