Sub-d Modeling

Hello,

First of all, I do not normally work with sub-d, but due to seeing that NVIL is put forward as being a sub-d modeler I though I should learn. I do know the basics, but wanted to look more at NVILs "Crease Subd".
In the help file it states that "Crease Subdivision":- "It is recommended that the mesh must be subdivided to at least level 3"
On my first attempts, NVIL either refused to apply the sub-d or crashed (out of memory- 1.3GB soft limit). So, to find limit of mesh size I could use(by default), I created a Sphere with a specific size(slices/stacks) to see what amount of polygons I could start with, before applying 3 levels of sub-d, however, I also need to take into account memory used by NVIL when it converts the mesh to .obj format for export.
So my process was to create a sphere of specific poly_count, add 3 levels of sub-d, then [attempt to] export as .obj file (when NVIL crashed/gave error, I would restart NVIL and start again). My findings are that I am limited to a base mesh(before sub-d applied) of approx 3,500 polygons. If I go beyond that, then NVIL will give error on .obj export of "Failed to save file: system.OutOfMemoryException"


To me, a base mesh of 3,500 polygons is very low for a sub-d modeler. Is it a bug or a limitation?

Thanks,

It's neither a bug nor a limitation. For a mesh of 3500 polygons, at subd level 3, it will be 4x4x4x3500 = 224000 polygons. When you export it, the program will first duplicate an object for exporting purpose. During the exporting to obj format process, there are other memory consumption requirement. Although there may be ways to reduce memory consumption, but it is not an easy thing to do.

Have you tried increasing your available rams?

also in many cases you are better off to stay at lvl1 or 2, and use support loops instead of creasing.

since with support loops your are refineing the edge shape, and your are also added geo around the edges to better define them at once.

It's neither a bug nor a limitation. For a mesh of 3500 polygons, at subd level 3, it will be 4x4x4x3500 = 224000 polygons.

If not a bug, then of course it is a limitation. A program can be limited by ram, in the case of a 32 bit application, by default approx 1.3GB. If during the process of sub_d -> export, the application is hitting its limit of Ram, then there is a limit of polygons the program can handle with its set use of memory.

When you export it, the program will first duplicate an object for exporting purpose.

Which can then double the amount of ram used.

During the exporting to obj format process, there are other memory consumption requirement. Although there may be ways to reduce memory consumption, but it is not an easy thing to do.

So again, there is a limitation of the amount of polygons the application can handle to export.

Have you tried increasing your available rams?

I have 8GB of Ram on 64bit system. But we are talking here of NVIL use of its soft_memory limit (address space) of (approx)1.3GB is can see/use by default for a 32bit application.

I can increase the amount of memory NVIL can see/use via LAA (to approx 3.5 GB), but that is a way to workaround its limitations, and not everyone will have the system memory to use or even know of LAA(Large Address Aware).

If we look at this from the point of the number of polygons created from the needed 3 levels of sub_d for crease_subdivision, which is showing at approx 224000. That can be seen as its limitation of polygons. Hence, before adding the needed 3 levels of sub_d, the polygon limitation is 3,500 for use of the crease_subdivision tool. That to me is logical.

also in many cases you are better off to stay at lvl1 or 2, and use support loops instead of creasing.

since with support loops your are refineing the edge shape, and your are also added geo around the edges to better define them at once.

From my limited use of sub_d modeling I agree, as I have always believed if you need more than 1 or 2(max) levels of sub_d then the initial shape is bad. However, first, we where talking about the limitation in reference to the specific "Crease_subdivision" tool, which is specifically put forward as needing 3 levels of sub_d(and on use agree, well, to get good results). We also need to look at the fact that even with 2 layers of sub_d you will still be hit by the polygon limitation, meaning a max mesh size of approx 14000 polygons before 2 layers of sub_d added, so that export can be made.

I really cannot understand how such a limitation is not classed as a limitation by IStonia.

ya i have had problems in the past, what i had to do, was export just the cage to maya, than subdivide there, than finally export out a sbm for xnormal to work on.

creasing i find causes a lot of problems with people new to subd since they see it as a replacement for support edges, when in reality it is a other tool to use beside support edges.

though also i believe there is something else going on than just lack of address space, since iirc zbrush is is only 32bit, and i can push to about 4 million points before i start having export problems, and to around 6 million before it slows down to much to be useable.

for reference, if it matters my system has 16gb's of ram, and 2gb of vram.

also if nvil copys the mesh with the subdivion preview on it, subdivides that than exports, would it maybe be a work around to just collapse the subdivision in the scene before the export?

ya i have had problems in the past, what i had to do, was export just the cage to maya, than subdivide there, than finally export out a sbm for xnormal to work on.

So at least not just me who sees the limitation.

creasing i find causes a lot of problems with people new to subd since they see it as a replacement for support edges, when in reality it is a other tool to use beside support edges.

I do not particularly like sub_d. I prefer to build and place polygons/detail only where I want to, not all over the mesh as sub_d does.
I was simply bringing this up after trying the tool and finding the limitation. (it could certainly be off-putting for others?)

though also i believe there is something else going on than just lack of address space, since iirc zbrush is is only 32bit, and i can push to about 4 million points before i start having export problems, and to around 6 million before it slows down to much to be useable.

for reference, if it matters my system has 16gb's of ram, and 2gb of vram.

Limitation of polygons (to available memory limits) are down to how the data is stored in memory.

also if nvil copys the mesh with the subdivion preview on it, subdivides that than exports, would it maybe be a work around to just collapse the subdivision in the scene before the export?

Sorry, I missed your edit in my reply.

Yes, you can collapse (make sure you then delete undo history) which allows for larger mesh output.

If you have not seen it yet, I would suggest you have a look at setting NVIL to LAA. There is an application which will do that for you [I use it without issue.] :- http://www.techpowerup.com/forums/showthread.php?t=112556 NVIL will then see/use approx 3.5GB of memory.

I would think that Zbrush is already set for LAA, but you can check with that application.

steve, can you show me the full error message? I just want to see at what stage the memory ran out.

Hi IStonia,

Can you not recreate the problem/error messages with the steps I posted?


These are 2 of the errors messages:-

The second message seems a bug. How did you get it?

Exporting a sub_d mesh and NVIL uses all memory.

Create sphere(65 x 65 or larger) -> level_3 sub_d -> save as .obj with option "export subdivision" When memory (approx 1.3GB) used, error message as seen.

If:- Create sphere(50 x 50) -> level_3 sub_d -> save as .obj with option "export subdivision". Then save OK.