View Full Version : Catmull Clark Edge Weight Freeze Optimization?

02-23-2011, 09:20 PM
Catmull-Clark Edge Weight it's a nice feature to tight the geometry and isolate influence without having to had more geometry. CC is very overlooked in LW modeling because of it's poor implementation. It's more useful for inorganic shapes, but maybe thats because it's not animatable yet

Now, talking with SlickSystems here in the forum, one idea came to mind, what if CC would subdivide according to Edge Weight Patches? This could drop down tremendously the amount of polygons in some models.

The general idea would be to have without freezing data generated or gathered at higher levels (lets say Level 1). This could influence the way the geometry is subdivided and they way UV maps are interpolated (giving birth to a new interpolation method where the UV islands look like the polygons frozen, bring more accurate).

A CCewPatch = UV Island. A bit like Nurbs i guess.


I guess this is not very impossible to do, even if it not at render freeze but as a modeling process.

But the big question is, even with the reduction of polygons going on, will it ease up the render time significantly? Or the amount of N-gons will increase it?

Anyway either if something like this is never implemented, it's a good mindset for modeling and cleaning up a CC Mesh.


PS: Although i know LW can't handle EW properly now, it doesn't mean it won't ;)

02-23-2011, 09:34 PM
I think it's doubtful that anything like this would ever be introduced to lw; but that being said, I always love your subd sheets! Very interesting concept and great execution on it either way!

I'd still be really happy if lw got the pixar subd like the new version of modo just added.

02-24-2011, 08:53 PM
eheh Jeffry, ty for the kind words =) Yeah, i also don't know what would actually be any good in this for a practical situation.
In what does polycount make a workflow chuckle, espcially, only after freezing? hmm...
Anyway for example, at CC level 3 with this tech and the object posted, i get 13,056-Tris > 7,876-Tris (-40%). At level 5 i get 200,712-Tris > 71,298-Tris (-65%). But Level 5 is so Impractical :P

As for Modo CC, well i don't see how different it is from LW CC when it comes to shape, oh but well... it works... ^^
(Ah and i don't know if it is because this method in particular but the new SubD also has multiresolution. Check (http://www.luxology.com/modo/tour/multiressculpting.aspx))


02-24-2011, 09:10 PM
it's just that the weighting is much better in the pixar subd as compared to what we have in LW.

02-24-2011, 11:27 PM
I wasn't really understanding the difference between them, then found a thread in blender foruns, talking about open boundary edges.
Apparently it solves them differently, LW does nothing; Blender pushes those vertices to cage position.

"Find out the differences"... 1 found :D

Slick Systems
02-25-2011, 03:34 AM
Hi Probiner,

I take your point about the bolt object being relatively easy to clean up however, it's still another process to do on top of modelling in the first place.

I again am enlightened by what you have posted regarding setting the backfaces to lower levels of sub d when freezing. I guess I don't get the time luxury to set up objects as thoroughly as that - usually I'm pushing the time envelope to it's limit just to get the job completed. Optimisation of models for me would be a problematic step as it would increase the amount of time spent with the objects in a scene. Even though it could reduce render times.

The problem for me would also have to include detail images. When I want to produce a close-up/macro shot of one of the objects perhaps an ani or a still, I would then have to create a secondary/tertiary setup with a hirez version of the object without the optimisation to enable a smooth sub d look.

Administratively it would then become too complicated for simple old me. :-)

BTW love the sub d CCew examples, have you ever noticed how round/cylindrical sub d protrusions when originated from a non-round shape are never 100% perfect round?

This is another issue I have with sub d meshes. I recently made one of our edge protection products from sub d's and there was a tube which had holes through its circumference rather like a flute. Because the tube had thickness and was made from a disc with say 12 sides (for the sake of example), when boolean'ing the holes from the mesh you can't sub d the tube because the resultant mesh is unusable.

So you look for a way to generate the holes without boolean and then you try the old bevel a circle from a square trick or similar. But once the hole is created and sub d's are applied the hole is distorted. (see example mesh), I find this even more irritating than the quantity of polys used. Oh, and edge weighting didn't help in this instance, from memory.

I came across an application which was a CAD type app and it's handling of these kind of surfaces was amazing and highly accurate (which you'd expect from a CAD prog) I think it was Alias Automotive (now owned by AutoDesk). The package used curves to describe how things bisected each other and then somehow combined the result to produce a suitable shaded mesh on-screen yet each of the component curves were still fully editable and the weighting of polys was optimised for detail areas versus flat/low detail areas. It looked like a complex bit of software and not for the faint of heart but it seemed intuitive especially to myself.

A mesh generated in such a manner could be frozen then sub'ded to produce a smooth object.

02-27-2011, 01:17 AM
Hey SlickSystems
I understand your point of view on the time consuming matter. The short answer and probably right answer for you would be to use NURBS. Since the these boolean and fillet tasks are easy and made on the fly. Right now you have for example MOI3D (http://moi3d.com/download.htm)(demo page), which has a very light and friendly interface that goes to the point.

Triangulated object was done with MOI3D, exported to OBJ (Tesselated) and took 3 minutes, the others are SubdS and they took much more time.
I was mostly picky with hole insertion, roundness is a bit overlooked on the bottom two.

[verbose mode]
SubdS;The long answer... (Really... go with nurbs...)
These require some planning.Some things you could consider about:

0- SubdS wireframes are not always reliable, sometimes a freeze helps to see whats going on. Also a 1024 sided or so, circle in the background is great for small eyeball tweaks.
1- Circles get distorteded inward. For precise measure this must be compesated. The main issue with this is more when an inward distorted area connects with areas without that distortion, but if they are aligned in the cage, something is going to pop out, like your example in the previous post.
2- Insertions in cylinders work best with the maximum of straight straight connections on the cylinder axis. For this reason you can many times have a different resolution of sides in the cylinder and blend between them to get more detail in the holes area.

3- One SubdS property that is always unintuitive: As long as you push the geometry in the hole axis, the radius will remain an intact , while you can improve the cylindrical surface. Like so:

My take on this is definetly with booleans, without Boolean =P I use Pictrix C_Form (http://translate.google.com/translate?u=http://www.pictrix.jp/lw/Cform/index.html&langpair=ja|en&hl=en&ie=UTF8), that is perfect to projects polygons to a cylinder segment and don't have all that clean-up with Boolean:
- Choose a cylinder side resolution for the hole area and for the other area. Size fix them and blend the two. Get a Curve from a segment for C_Form.
- Size fix the hole profiler and project it with C_Form to a . Get a good polygons loop around the hole and skin the hole to the caps. Tweak
- Apply Edge Weight. Tweak.

This way you can have a cylinder with with a hole with precise sizes when frozen.

Edge Weight does help to tight up things without adding more geometry. (In the object attached, you can select the surface called Edges and then 'Select Outline Edges', to the weighted edges)
[/verbose mode]

(Bla bla bla bla... Nurbs) :)

Slick Systems
02-28-2011, 04:05 AM
Esentially Probiner,

You have hit the nail on the head with this one, I pretty much came to the same conclusion regarding the sub d scenario. Nurbs are definately a better solution for this type of problem.

My only reserve with nurbs is that they seem to produce a heavy poly mesh, especially if you have to freeze the object after modelling to get it back into LW. The problem then becomes the same as when we started talking about the bolt - too many polys and if the object needs to be cloned multiple times...

The only answer I can give to this would be Core. When it finally arrives in a stable version, it should have instancing built in which would then mean clones would not add additional overhead to scenes as I understand it. When this happens the complexity of the object shouldn't impact too much on the scene performance hopefully!!

02-28-2011, 08:13 AM
DP Instance doesn't cut for you?

Slick Systems
02-28-2011, 08:16 AM
I tried with HD instance but found it too slow and in addition the surface rendering was not 100%.

I havent tried DP Instance but I'll look into it, Denis could do with a better website to display all his plugins, one that is also easier to find.

Only issues I can see from looking at his page are that it's a volumetric plugin just like HD instance and therefore will have a major trade off in render times.

I guess I must be being unreasonable eh?! :-)

02-28-2011, 11:03 AM
I think made this comment before in this forum. This freezing optimization is a good idea but don't see it implemented soon.

Catmull was first implemented in Pixar's RenderMan. The way a SDS is tesselated goes in relation to the size of the micropolygons (micropolygons are related to the size of a pixel), so if an object is closer to camera has more micropolygons and thus more subdivisions, if the the object is farther, then the number of tesselations goes down. I like this smart way of optimizing geometry.

Slick Systems
02-28-2011, 11:15 AM
Titus: that is also a good idea of handling geometry resolution doesn't LW already have a per pixel sub D parameter? is this not the same type of geometry optimisation, perhaps LW handles it in a different way.

You can fake this type of behaviour in LW by using a low rez proxy object which gets swapped at closer camera distances but again it requires much setup to achieve the best results.

Normal mapping/displacement is also another method of achieving higher detail using a low resolution mesh but has similar flaws to the sub D mesh problem in that if required to produce a real close up detail the low rez cage will always show up in the end.

I can see this becoming a non-issue in years to come when machines bet more and more powerful the sub d/poly heavy problem will affect us less and less. There still remains however the other issue of sub D accuracy which is a problem.

There has got to be a better method for applying nurbs/subD type surfaces in applications. Most CAD type apps have had the ability to achieve these kind of meshes for ages and they can handle massive amounts of data without breaking a sweat.

Apps that can output IGES files for manufacturing purposes Solidworks, PROE and the like handle this kind of thing with ease. Surely an adaptation of their techniques could be adjusted to fit with LW then we would all benefit from the advantages.

02-28-2011, 03:15 PM
Are PRman divisions tied to the cage polygons average values like LW's "Pixels per Polygon" or the divisions are made freely along the surface?
Meaning, in LW you get a level of subdivision assigned to each polygon by its average parameter, so each polygon is divided in X*X which will result in a patchy look, because the level of division is set per polygon. In the image, a small cylinder viewed from a skew perspective. My question is if PRman will continue to tessellate polygons so that the projected density looks even?)

@Slick Systems
Eheh, maybe CORE and LWCAD 4 (apparently with NURBS (http://www.wtools3d.com/manual/manual3/assets/video/Nurbs4/Nurbs4.swf)) will make you happy and not unreasonable at all =P

02-28-2011, 03:46 PM
My question is if PRman will continue to tessellate polygons so that the "grid" looks even)

Well, PRMan works a little different. Every polygon is split (dicing) at the end into micropolygons the size of a pixel, they all look even:


02-28-2011, 04:23 PM
Gaahh you answered before i edited. By even i meant projected density to the camera, and if parts of a single polygon would continue to being diced while others (that already became smaller than a pixel) would stop being diced.
Even if a polygon is in your "face" but it's completly flat or part of a cylinder, i don't see why it should be diced so much (not including displacements).

Anyway ty for the link. I had been reading some stuff and it's hard to visualize.

I guess this CCewPatches would be very very specific (I see few examples of ppl using Edge Weight, don't know why) and beaten by NURBS anyway for smooth inorganic modeling purposes.


Slick Systems
03-01-2011, 02:10 AM
Probiner & Titus: Yes I see what you mean about PRMan, but Probiner is right, I would prefer to see selective density division if that makes sense as probiner suggested but in my case I'd like to see it as an additional tool in LW.

One reason for why sub D may add additional geometry to meshes is down to the way in which it calculates a divisional surface based on the low rez cage. As Probiner has already mentioned geometry gets distorted when using sub D therefore to retain at least some semblance of accuracy a flat area needs the divisions to allow the polys at ends of cylinders for example to be undistorted (to a degree).

I don't really see how this can be avoided with sub D as the whole mesh becomes almost elastic and springs to fit the cage. Adding edge weighting is one way of tackling the problem but why cant there be a tool that understands the edge weight parameter and then adjusts the density of the mesh accordingly? say by adding additional loops at a tight edge and less within a flat area. However this is all very well but in the bolt case there is no other way of creating that shape without the amount of poly's that were required in the first place, unless there could be a n-gon type poly which twists around the thread of the bolt from one end to the other then only a few polys would be needed to create that shape (almost like peeling an apple). This is probably unachievable? as it wouldn't render correctly unless the sub D type surface could interpret these special case polys and split them at render as does RMan.

I can see that Renderman has a method for dealing with the geometry at render time but this is no good anyway as we're not talking about 'at render time' we're talking about the mesh/model in the first instance before it even gets to render stage. The RMan implementation is excellent for rendering purposes but does not solve the initial modelling problem in the first place.

The only way of reducing the polys in the bolt would be to reduce the circumferential divisions to the bare minimum needed to create a reasonable circle say 6 (4 doesn't produce a circle it produces a rounded square shape). Even then for long tight thread bolts the thread poly count would be large. Imagine having say 20 to 30 of them in your scene in addition to all the other mesh poly count would go through the proverbial roof, or is that through the mesh? :-)

I look forward to LWCAD 4 although by the time that arrives I probably won't be able to afford it. ;-).

Hope this makes sense.