Inside Sabertooth
Learn how Sabertooth uses 3ds Max to create 3D interactive projects, including HBO Go’s Game of Thrones interactive experience
  • 1/3
You are here: Forum Home / Autodesk® Mudbox™ / Suggestions / ptex mipmaps , transfer maps, multi-channel
  RSS 2.0 ATOM  

ptex mipmaps , transfer maps, multi-channel
Rate this thread
 
59302
 
Permlink of this thread  
avatar
  • conflict
  • Posted: 22 August 2011 04:40 PM
  • Total Posts: 6
  • Joined: 28 August 2006 08:37 PM

I’ve been developing our Mudbox-Ptex-Vray workflow.

1. My only hesitation with committing to ptex is changing geometry. My contact at WDFA tells me that their internal paint app has tools to raycast/transfer maps from one mesh to another. What’s the roadmap for Mudbox and transfer maps to support ptex.

2. Are ptex files from mudbox mipmapped? I know they are in Mari, and I don’t need my renderer to load the full dataset.

3. Is support for multi-channel ptex on the horizon. I hear it’s in the file spec. That way a single file and a single file handle, since the render keeps it open for reading different levels, can load all your maps - diff, spec, occ, etc.

Thanks.



Replies: 0
avatar

1. Mudbox’s Tranfer Paint Layers (under Maps>Extract Texture Maps) transfers paint to and from ptex textures, precisely for the reasons you’ve raised.

2. Yes, they are mipmapped.

3. Mudbox currently supports single-channel/ptex files, however there is nothing to prevent us from supporting multiple channels if this becomes a requirement from our customers.



Replies: 0
avatar
  • conflict
  • Posted: 24 August 2011 08:44 AM

Andrew Camenisch 24 August 2011 02:39 PM

1. Mudbox’s Tranfer Paint Layers (under Maps>Extract Texture Maps) transfers paint to and from ptex textures, precisely for the reasons you’ve raised.

2. Yes, they are mipmapped.

3. Mudbox currently supports single-channel/ptex files, however there is nothing to prevent us from supporting multiple channels if this becomes a requirement from our customers.

Andrew,

Thanks for the reply! (I actually worked with your cousin Daniel Camenisch on a video shoot for Barlow Girl! He mentioned you were a skymatter developer.)

1. I’m having trouble with this. Am I missing something? I need ptex -> ptex.

I couldn’t actually transfer paint layers between ptex meshes without going through traditional UVs at some level. When you use a ptex prepped model and transfer: “At least one target mesh does not have UV data”.

This is the workaround I came up with. It is possible to use an object with a traditional UV plot as the target, then ‘uplift’ those UV’s to ptex. My question is about how to maintain resolution parity between meshes. If transfer paint layers, and set ImageProperties>Image Size: Same as Source, it defaults to 2k for any ptex source. That would mean that I would need to determine which faces need a greater UV area, and also some way of visualizing the number of face ptex subdivisions to make the ptex resolutions match. (see feature request below)

I did notice that when you export an obj, it generates per face UV data that corresponds to the ptex resolution.

So the workaround could be prep the target for ptex with multi res, export obj, import obj with that approximate UV data, then make a 8k texture file during the transfer map operation, then finally uplift to ptex. That would work up to certain resolutions, but if you needed more, you would have to scale your sized uv’s in maya into several tiles, then extract, then uplift.

Is there a approach that will match the tile resolutions? Again, I could have missed something.

I’d like to mention a feature request as well. Provide a color or number coded ptex subdiv level display per face. It’s nearly impossible to determine the actual face resolution with the current ptex setup methodology. It’s pretty slick as is, but not specific enough.

2. Good to know they are mipmapped. I wanted to make sure the renderer wasn’t needing to load the highest level.

3. If Mudbox would implement it, you could have more than 4 channels stored in a ptex file. You could paint diffuse, spec, and bump layers in Mudbox, then write out a single ptex/multichannel exr to hold all of the channels. Then in the V-ray ptex reader you could choose which channel to load. It would help with workflow and limit the number of open file handles in the renderer.

As an additional feature request, exporting multichannel EXR/Ptex files, then expanding the ‘file’ node in maya to support reading those multi channels would be great. For vray, you’d need to coordinate with Vlado at Chaos Group, but those guys are super fast at adding features, and I’ve seen a couple requests for it on their forums already, with Scott Metzger (his idea) pushing the Mari folks to do the same. It would be a really nice way to keep the number of maps down and organized.

I’d be happy to clarify if I haven’t been clear. Thanks for the response!



Attachment Attachment
Attachment Attachment
Replies: 0
avatar
  • conflict
  • Posted: 24 August 2011 09:04 AM

Andrew,

Here is a mockup of the ptex resolution display.

There would be issues if the face size got too small, so perhaps it could be number or color or both.

Zach



Attachment Attachment
Replies: 0
avatar
  • conflict
  • Posted: 24 August 2011 01:01 PM

I couldn’t get this concept out of my head today.

A multi-channel texture file seems like a pretty fantastic idea. I obviously don’t understand the implications for memory and performance for rendering, but on the surface it seems like an awesome concept. I can’t believe it hasn’t already happened! The vray node is basically good to go, and maya needs a multi-exr loader for standard UV maps.

If the rendering folks say it won’t be any slower, and the paint app folks implement it…
The old workflow wouldn’t go away, there would just be this new streamlined option.

1. File management. Much simpler to have a single map per object, rather than several tiles, and several layers, adding up to tons of maps and versions.
2. Fewer open file handles. Vray keeps an open file handle for tiled exrs and ptex since it reads the mip levels. It would only need to open the file once, even though it could be several gigs in size.
3. Simpler shading networks. This could be good and bad. For ptex, it’s fine, done. No placement attrs. For multi-channel exrs, the ‘file’ node could get messy if you wanted to change the 2dPlacement. You might need a ‘shuffle’ node like you have in nuke, but implementation would just be as simple as having an index for each channel in addition to your rgb/channel id assignment.
4. Shared alpha information.
5. Standard channel assignment. 0123 =a+diffuse, 4457=a+spec, 891011 = a+bump, etc. Might make hooking up shaders very fast. Probably not practical if ptex didn’t allow empty channels.
6. Fixed resolution. This is a negative, if you wanted a lower res diffuse, and a high res spec.



Replies: 0
avatar
  • oglu
  • Posted: 25 August 2011 01:28 AM

multi channel ptex sounds interesting…



http://www.linkedin.com/pub/christoph-schaedl/6/558/73b

Replies: 0
avatar
  • conflict
  • Posted: 28 August 2011 08:09 AM

I’m having trouble with texture sizing with ptex in mudbox.

When I read the original ptex presentation, it looks like the issue is solved, but in my test, it’s not solved.

Is mudbox using the WDFA solution for texture distribution? If so, I need to take the issue up with Chaos Group.

1,2 show WDFA mapping solution

3, shows my result in vRay with 3 levels of subdivision, you can clearly see the stretch.

4, shows my painted object, in mudbox, with 3 levels of subdivision

5. shows base mesh, without subdivs.

Is mudbox aware of subdivs?



Attachment Attachment
Attachment Attachment
Attachment Attachment
Attachment Attachment
Attachment Attachment
Replies: 1
/userdata/avatar/avatar_200002.jpg

When distributing texels, Mudbox takes into account the size of faces *at the highest level*.  So for a subd workflow be sure to subdivide the model several times (and either sculpt or apply any displacements) *before* setting up ptex.

Author: Andrew Camenisch

Replied: 28 August 2011 05:09 PM  
avatar

Your images didn’t load.  It would be nice if pTex could create a UV map that didn’t consist of a bunch of tiles.



Replies: 0
avatar
  • conflict
  • Posted: 29 August 2011 07:40 AM

Thanks! The vray folks are working on their filtering to fix the issue.

What am I missing to get ptex -> ptex to work?



Replies: 1
/userdata/avatar/avatar_200002.jpg
conflict 29 August 2011 07:40 AM

What am I missing to get ptex -> ptex to work?

Sorry, I’m not sure about v2012, but this is working fine in the 2012 SAP release (available soon).  I just tried it.

Author: Andrew Camenisch

Replied: 29 August 2011 10:12 AM