PDA

View Full Version : thought about why lw's CC Subds are so slow...



jin choung
09-02-2007, 02:47 AM
howdy,

so i learned something new about maya's subds that i had no idea about until recently.

i always b!tched that maya's subds were kinda lame because instead of giving you the ability to define arbitrary levels of sharpness on an edge or a vert, they force you select between 3 discrete levels.

1. normal
2. creased - infinitely sharp ... basically unwelding effect
3. semi-sharp

i was thinking, COME ON! wtf?!?! is this because of pixar's patent on CCs and they are using a licensed version of ccs?

HERE'S THE EPIPHANY:

you can apply 3. semi-sharp MULTIPLE TIMES!!! D'OH!!! so you can indeed get DEGREES OF SHARPNESS that you can control!

HERE'S THE OTHER SHOE:

the more times you apply semi-sharp, the SLOWER YOUR MESH BECOMES!!! because of the nature of HOW THAT SHARPNESS IS BEING CREATED (basically creating more detail at the edge on successive subd levels, the final edge sharpness being visible on the limit surface).

-------------------------------------------------------------------------

THEY RECOMMEND THAT YOU DO NOT USE VARYING DEGREES OF SHARPNESS MUCH UNLESS ABSOLUTELY NECESSARY FOR THIS REASON!

but without edge sharpening, the mesh is fast and responsive and subdivided beautifully (that is, better than lw's default subds or exactly like lw's metaform subdiv algo).

--------------------------------------------------------------------------

so maya only incurs the slowdown when edge sharpening.

ours is slow all the time.

here's my thought:

CAN WE, LIKE MAYA, BREAK IT UP? so that the slow down only occurs if we insist on edge sharpening?

otherwise, we run fast and furious with good looking subds?

waddya think?

jin

mav3rick
09-02-2007, 03:00 AM
i dont think i am waiting.. and modeling in cc at the time

SplineGod
09-02-2007, 03:42 AM
Another thing to consider is that the subpatch level settings between standard Subds and CCs arent the same. CCs produce way more polys for the same subpatch level then standard subds. I usually set the subpatch level very low for CCs.

hrgiger
09-02-2007, 04:31 AM
Another thing to consider is that the subpatch level settings between standard Subds and CCs arent the same. CCs produce way more polys for the same subpatch level then standard subds. I usually set the subpatch level very low for CCs.

Yes, I keep hearing this excuse. Jin is not talking about the comparison between Lightwave's standard subpatch and the new CC. The fact is, even at low levels, CC performance in Lightwave is unnecessarily slow.

jin choung
09-02-2007, 05:04 AM
right.

and unecessarily slow because we can compare to other apps that do it quick and speedy.

heck, even BLENDER IS FASTER! BLENDER!

so anyhoo, the engineers should look into it because maybe they implemented edge weighting non ideally? the should see if they can split off slow downs and make the degree of sharpness affect performance?

jin

vadermanchild
09-02-2007, 05:33 AM
I can or cannot assure this might be getting looked at and and that a statement on CC within lightwave will be made at some point in the next dev cycle...or the one after that.

jin choung
09-02-2007, 05:36 AM
oooooooo.... that's a one SPICY meatball....

jin

voriax
09-02-2007, 08:02 AM
Yeah it's not some edge sharpness thing thats slowing them down .. they're just slow. LW's edge sharpness doesn't add any more geometry to the corners anyway.. I thought that it pulled more geometry to the edges to sharpen them up, but it doesn't even do that. It simply creates a sharp edge with the geometry it has.

CC's are especially slow in Layout when using them with bones. Setting it to subdivision level 1 on a relatively simple character object still brings it to it's knees (on my comp at least), whereas the same character as subpatches will fly along, even with a higher display poly count.
Same with the Modeler side of it. They're just slow. For now, at least.

9.what?
09-02-2007, 12:56 PM
yep slooooooooooow,
and we have had 2 point releases since they were added. Why do they still suck? Newtek you are letting down a lot of people. I am less then impressed with what you have accomplished. I am beginning to realize that there will never be a new LW, just snippets of code that almost work together!
If you hear splashing... that is the sound of all your customers jumping ship.:agree:

Ztreem
09-02-2007, 03:54 PM
I don't think it's so much the CC's or OGL that is slow, it's the mesh edit and handling code that is old and slow and they are working on it. Wait until the new code is in place and then complain if it's slow. Just have a little patience...

Captain Obvious
09-02-2007, 04:09 PM
heck, even BLENDER IS FASTER! BLENDER!
Come now, there's no reason to belittle Blender! It's actually faster than Lightwave at most things (except the built-in renderer, the last time I tried it).

gerry_g
09-02-2007, 05:51 PM
Agree with Ztreem gotta be the code, even when you're on one layer or most of the object's hidden LW is still grinding through it's database for the entire object, and if you hit 'N' and copy what your working on into a new empty object suddenly it runs a lot better.

jin choung
09-02-2007, 07:53 PM
i'm not belittling blender. i love blender. but it's FREE! i'm saying even a COMPLETELY FREE APP is faster!

jin

Jarno
09-02-2007, 11:14 PM
There are several reasons CC subd isn't as fast as people would like.

In Layout it's because if you change something that may alter the vertex positions before the CC subd is computed (e.g. subdivision is set to happen after bones), the subdivision has to be completely recomputed. Layout has a very all-or-nothing view of mesh changes.

In Modeler it's because the CC subd code is rather complex so that it can attempt to deal with all the insane polygons that LW allows. No other package is as forgiving to atrocious polygon shapes as LW. Most other packages have restrictions on polygon shapes that are supported for subdivision and other operations. There are also problems with how fast LW can construct new meshes in memory.

Polygons with holes in them, using the same vertex more than once in the same polygon, using the same edge more than once, more than two polygons sharing an edge, one polygon joining another at more than one vertex without sharing an edge, it's nuts! I'm certain it is possible that just about any mesh could be created using only a single so-called polygon.

I'd love to completely redo CC subd, only having it work with sane meshes (e.g. up to 16 vertices per polygon, polygons join each other either at one vertex or one or more sequential edges, no holes in polygons, each vertex used no more than once in a polygon). But one of the reasons people wanted to have CC subd was because they had meshes on which subpatches didn't work.

---JvdL---

jin choung
09-02-2007, 11:51 PM
yes, insanity should be frowned upon. and the people who want insanity will just have to suffer with a much faster implementation of ccsubds... boo hoo.

as for layout, well the situation would be the same with ccs as it is with native subds but native does much better.

imo, an ugly but doable solution is CACHE the subd level when possible so it doesn't have to be recomputed for deformation. the cache is disabled for rendering of course.

anyhoo, it's slow and that ain't cool.

jin

hrgiger
09-03-2007, 08:27 AM
So part of the reason that Lightwave's CC's are so slow is because Lightwave allows such sloppy modeling practices that other packages won't allow? And this is somehow a good thing? I don't see the point in allowing Lightwave to subdivide a mesh that has polygons with 16+ vertices. Perhaps a new iteration of CC's is in order that has such restrictions that may allow us to use CC's with better performance?

achrystie
09-03-2007, 10:06 AM
There are several reasons CC subd isn't as fast as people would like.

In Layout it's because if you change something that may alter the vertex positions before the CC subd is computed (e.g. subdivision is set to happen after bones), the subdivision has to be completely recomputed. Layout has a very all-or-nothing view of mesh changes.

In Modeler it's because the CC subd code is rather complex so that it can attempt to deal with all the insane polygons that LW allows. No other package is as forgiving to atrocious polygon shapes as LW. Most other packages have restrictions on polygon shapes that are supported for subdivision and other operations. There are also problems with how fast LW can construct new meshes in memory.

Polygons with holes in them, using the same vertex more than once in the same polygon, using the same edge more than once, more than two polygons sharing an edge, one polygon joining another at more than one vertex without sharing an edge, it's nuts! I'm certain it is possible that just about any mesh could be created using only a single so-called polygon.

I'd love to completely redo CC subd, only having it work with sane meshes (e.g. up to 16 vertices per polygon, polygons join each other either at one vertex or one or more sequential edges, no holes in polygons, each vertex used no more than once in a polygon). But one of the reasons people wanted to have CC subd was because they had meshes on which subpatches didn't work.

---JvdL---

Maybe I'm not understanding you, but are you saying it is slow because of open meshes and ngons? I find this very hard to believe. I have Silo and I can subdivide quickly and spin/edit the model in real time with pretty much any shape (any ngon), and any form of "open mesh" geometry.
The only geometry that "doesn't" subdivide properly with CC Subd is non manifold geometry (edges with more than three faces), but this is a problem inherent to the CC algorithm, not the program.
The process is obviously limited by my RAM, as with any program, but that gets me rougly 1 million polygons on a single mesh, and I can still work with it, even with only a GeForce 6600 card and 1GB of ram.
I don't see why LW can't replicate this, other than the new CC code and or the architecture it's programmed into, is not optimized properly.
This is one of many reasons I don't use LW modeler.

ABC

ColinCohen
09-03-2007, 12:51 PM
I don't think you can truly know the cause of the slowness without intimate knowledge of the source code.

Sensei
09-03-2007, 02:15 PM
I'm certain it is possible that just about any mesh could be created using only a single so-called polygon.

Like EasySpline http://www.easyspline.com is showing it in practice..



I'd love to completely redo CC subd, only having it work with sane meshes (e.g. up to 16 vertices per polygon, polygons join each other either at one vertex or one or more sequential edges, no holes in polygons, each vertex used no more than once in a polygon). But one of the reasons people wanted to have CC subd was because they had meshes on which subpatches didn't work.

Ways to speed up CC/Sub-D:

- keep tract of point position in polygonhandler->Update() and update only those patches that really changed between cage updates, instead of recreating everything.. dragging point will result in (usually) recreation of just 4 patches that are using dragged vertex. Then you can have 1 mln patches and dragging in absolute real-time, like in EasySpline...

- forget about low-memory usage by sub-patches and in polygonhandler->genmesh() generate mesh once and keep in memory instead of recreating it all the time LW wishes to.. In EasySpline backing up data resulted by 300% or more speedup in spinning perspective viewport.. If you're worring about hi memory usage make option in the config that limits how much backup buffer is taking memory. In low memory situations it can go to standard current way of doing it..

- using multi-threading in Update() to speedup generation of meshes (and in that case replace polygonhandler->genMesh() functionality, which is called once for each patch, so can't be multi-threaded)..

RedBull
09-03-2007, 04:19 PM
I can use some pretty weird ngons in Modo and Silo and CCs aren't slow there. I need further convincing that this is indeed the issue. :)

Ummmm, Correct me if I'm wrong but Modo doesn't even support CC's?

And there are many difference in the way for example XSI and Silo handle there,
CC's implementations, so hardly a surprise that LW would differ too.

jin choung
09-03-2007, 04:30 PM
but other differences aside, the primary difference is that maya, xsi, silo et al handle ccs...

WELL.

jin

jin choung
09-04-2007, 01:41 AM
neverko,

but is their subdivision surface implementation CATMULL CLARK? i think that was redbull's question.

jin

jin choung
09-04-2007, 01:42 AM
oh,

cuz just because a subdiv surface supports ngons, it doesn't necessarily mean that it's CC.

newtek kinda lumped that in there but i'm not even sure if that is a spec for CC.

jin

Nemoid
09-04-2007, 06:16 AM
I think Modo uses CC model, but its own implementation to be faster.

in facts it has some quirks if , for example compared to XSI implementation

http://forums.luxology.com/discussion/topic.aspx?id=19373

that said, when i tried Modo subds were quite fast. you can model entirely in subd with it and use ngons too in the process if you want.

RedBull
09-04-2007, 07:32 AM
Thanks...

Yeah I'm pretty sure Modo's SDS supports NGons, but as far as i'm aware it's not using CC's.... (I've looked in my manual and on the Lux site and never found any mention of CC's throughout 20x cycle)

Luxology recently announced that they have made a technology swap with Pixar so I'd expect that Modo will support it at some stage...
But at the moment it would be incorrect comparison to compare the speed of Modo's SDS to LW's CC's... XSI does have the fastest OGL and CC's in the business... Besides Modo is so bad at highpolycounts.. I'm not sure you would want to compare anyway... :)

It seems Jarno and the team are aware and have commented on some reasons as to why and how it can be improved in LW, So let's hope it eventually is... Good luck catching the OGL freak of nature that is XSI... :)
LW is still slower than Modo/XSI/Maya in OGL performance, so it's not just CC"s where these applications are faster.

Captain Obvious
09-04-2007, 07:37 AM
Besides Modo is so bad at highpolycounts.
Oh, you'd be surprised.

Andyjaggy
09-04-2007, 08:03 AM
couldn't be any worse then LW with high poly counts.

Captain Obvious
09-04-2007, 08:08 AM
I just loaded up a massing model of most of Moscow, a grand total of 3 800 000 polygons. The main bit is a sky scraper, total about two million polygons. It's all being rendered at about 20-30 frames per second, with per-pixel lighting (ie, normal/bump map support, spotlight cones being drawn accurately, etc) with FPrime running in the background! modo's pretty fast with heavier scenes. Without LW/modeler/FPrime running, I could probably load up several times that number of polygons and have it silky smooth.

RedBull
09-04-2007, 04:04 PM
Oh, you'd be surprised.

Why?

Nah, I really wouldn't....

I use Modo everyday it's just really really bad with complexity....
It's overcleverness gets in it's way, things like highlight or preselection cause Modo some massive slowdown headaches..

Anytime you want to test the largest object Modo can handle in the viewport
compared to LW you just let me know.. But again, don't bother me until you have at least 11million raw polygons in the OGL viewport, no instancing or MPD... Because LW can manage this on a 2Gb 32bit machine.


couldn't be any worse then LW with high poly counts.

That's just the point LW can handle high polycounts as can Maya/XSI/Max.... Modo cannot handle them at all...


I just loaded up a massing model of most of Moscow, a grand total of 3 800 000 polygons.

You mean Modo can handle 4Million without running out of memory?
(Wow Zbrush and MB would be scared?) :)

Captain Obvious
09-05-2007, 03:12 AM
Lightwave with the same scene runs at about half a frame per second, and doesn't render with two gigs of memory...