Selection tool problems

#1--Everyone at my studio is having this problem. Our Obj’s typically have 20-60 material groups. In Mudbox 1, we could select individual materials in our object list and hide them. In Mudbox 2009 if we try to select more than one material at a time everything becomes selected. We cant select just a few at a time anymore. I’ve resorted to painting my selections and creating selection sets but it’s time consuming and not as accurate. Anyone have a solution to this?

#2-- the “show selected” option doesn’t work either.

#3--If we try to paint a selection at higher subdivisions and hide it, it’s sometimes inaccurate and chunky in appearance.

#4--probably not a bug but a limitation--Mudbox only remembers whats been hidden at a particular subdivision level. ex. If I hide half my model at subdivision 3, when I step down its no longer hidden.

Work arounds or help anyone?
Thanks

Your observations are correct. We have been looking at these areas for some tweaks.

May I ask why you feel you need multiple materials and why are you ever hiding in your specific case? Is this for performance reasons?

Thanks

Hi:) sorry it took me so long to respond.

Actually it does really comes down to it speeding up our performance when regions with large amount of polys are hidden.  In general to achieve the desired level of detail we might subdivide, for example, a face material to 10-15million polys, (5 million on the low side) a hand will be subdivided to 5-10 million polys, A torso 5-10 million. We cannot work on a full model and expect to be able to achieve the level of detail desired. This is the same reason that we’d like materials to remain hidden regardless of our stepping up or down in subdivision until we choose to unhide it. The selection tools you had in Mudbox 1 was a good way to help us keep up a good pace and work flow.

I would like to suggest a new workflow for you based on how we intended Mudbox 2009 to work with very high res assets. We re-designed the entire rendering system to improve upon the local subD limitations of version. It sounded great on paper but introduced many issues. What we have now is a fully automated local subd system in Mudbox 2009.

V1.07 limits
-Heavier file sizes
-Local subd you can not view the entire mesh and work across assets quickly
-Slow rotation of dense objects
-Slow brushing of dense objects
-Hide and show slows workflow
-Complications for extraction
-Subdivision change level speed slow
-Cant light and shadow dense the mesh
-Extra ram needed for local subD
-Cant show art director entire asset at once
-low limits in how how you can directly subdivide entire on 32 and 64 bit OS
and more… Just because of the way subdivision worked.

Basically the way the system is designed now you can subdivide further and rotate more faster in Mudbox 2 than Mudbox 1 while being able to view the entire asset and work across it and then extract a map from this.

-For the poly counts you are working with I recommend 64bit Mudbox and minimum 8 gig ram.

-The lower the base poly count the faster the rotation will be at higher poly counts.

-If the mesh is all quads ( you can force this by subdividing any base mesh once ) and the Mesh Prepossessing option is on in the prefs before import you gain additional performance. I will post a screen shot of what I mean.(This will re-org vertex ids but this is not an issue if you are just extracting a map )

I will post some more details but hiding based on materials is not the way we intended for you to work with a model that has multiple parts and you need to subdivide each to 10 million.

more soon…

Tips for organizing your scene so you can hide show parts:

Try and create Sets per face or per object in Maya(for example) before export of the obj.(In Maya Create>Sets>Set [option box] )
You can create simple Mel scripts to create a set per material or per object.

Make sure Groups and Point Groups are turned on in the Obj export options.

Mudbox will see the sets in the file and create selection sets for you. You can use these for hiding a showing parts of the model or various objects.

HI Skycastle,

Thanks so much for the help. If we dont have regular access to Maya we can create our own selection sets in Mudbox correct? Same thing? the way we’re set up we have limited access to maya and limited control over Uv’s unless there’a a problem and we kick it back to our modeling department. I’d like to keep as much of our sculpting workflow contained within mudbox.

Also, we do have a 64bit system with 8 gigs of ram, we’re low on video ram, some have 640 some have 320. How much of a performance lag should we expect while working? I know how fast we could work based on personal demos but due to current hardware constraints everything’s moving very very slowly during certain operations.  I’d estimate at least 60 percent slower then the ideal we’ve been shown with the recommended video ram.  I dont expect Mudbox to perform beyond our hardware limits but I’d like to know if this is what should be expected with current hardware configurations.  Or if not do you have timed bench marks we can compare to?

Here are our estimates below:

--when selecting our high levels(in the object list) in preparation to export out a map it could take anywhere from 2-5 minutes
--stepping up or down in subdivision could take anywhere from 15seconds to 3 minutes(high estimate would be stepping up from around 2 million to 8 million polys)
--exporting out 32bit maps at 2k with 16 material groups approx 15 minutes
--exporting out 32bit maps at 4k with 16 material groups approx 25-30 minutes
-- creating maps based on scan data that was around 1million polys in size (from time of opening it in mudbox , selecting our high level and low in the baking menu and exporting out 10-2k maps sucessfully (35-40 minutes)
--
Does that sound right to you? the funny thing is that my personal demo copy at home seems to run smoother using a 32bit system with 2 gigs of ram and a 256 video card. Is there another hardware issue that we should be looking at besides our video cards?

We will definitely incorporate your suggested work flow.  Thanks again for all your help I really appreciate it.
--ssky