the second option is definitely nice but when it does not work on discontinuous meshes and majority if not all of my retopo work involves creating a lowpoly retopo on multiple highpoly meshes at once.
what i would do in that case is what i would do with scans that are to big to deal with.
first decimate all your pieces so they are light weight then merge all the pieces and resurf.
you can then uv and pull maps as normal on your cage.
edit:
the decimation step is alway a good idea because it speeds up mesh gen and any other operations. then you can swap out with you highres at the end to pull maps.
nice! that is a pretty good work around for small sculpts.
makes me wonder if this workflow can adapted into the retopo feature so that the discontinuous mesh error doesn't appear.
anyways, topologically merging bigger highpoly meshes is not an option in most cases.
can you imagine topologically merging something like this : http://cghub.com/images/view/313202/
the main point is that you can very easily resurf across object and works quite well.
the secondary point is that decimation and merging is not only always possible but usually the best approach. you can tune your overall polycount to a manageable size and merging decreases the amout or memory used and the amount of calculation needed as most of the algorithms work on front facing polygons. even if the tools are available to handle it i would not resurf on un-decimated hires and keep everything separate. and i whould have no problem decimateing and merging chunks of that model for resurf. in fact i have seen worse.
if you do some tests with that droid and decimate and merge chunks i think you will find it quite a solid technique once you get the hang of it.
edit:
the decimation in 2014 is better then the old decimation technique i was using in another package and its faster.
Well I hope they get rid of the bug where I can't select an object in the object list, or where I can't select an object and that object is also hidden...
having more buildup is the correct behaviour. the stamp space is applied with the brush intensity that 'you' set so if you decrease the stamp space then you are going to get more stamps applied over the same area. if you wanted to be able to increase or decrease the stamp space to what ever you want and have the brush have the same intensity then the algorithm would have to take the average and adjust the intensity of each stamp to something other then what 'you' entered as the actual intensity value. i would never want that. i what the value that is input to be the actual value that is applied for each displacement stamp. you could end up with all kinds of crappy brush behaviour if the algorithm starts to decide what value to apply per stamp and disregard the actual value you put in the tool option. its much better to just manually adjust your stamp intensity to counter act the buildup. in some cases you can use buildup to get certain effects from stamps anyways which is a nice feature of how the brushes work now.
edit:
if anyone is interested in the basics of how to use VDM's then there is a great video on area that shows you the basics.
Yeah with a file I encountered yesterday, I have a piece of geometry that is hidden and unelectable. Even after doing similar to above, as well as a few other things it remains broken. I've had it happen before and managed to fix it, but can't remember how
if you want to take accurate screen grabs from mudbox you have to lower the 'fast render scale value' so there there is no tessellation on your object. mudbox uses a kind of subdiv / tessellation based on camera distance. you can adjust the effect that this has or turn it off. you can find the settings in the preferences.
I take back what I said about the bug for saving as .mud
For Resurfacing with Curves. I find that there are a lot of times that i get holes in my mesh even tho i drew the lines to intersect as those points. My gripe is that it takes lots of tweaking to get a water tight mesh. And I missing something in my settings?
the only workaround i found so far is to patch the holes in mudbox and then run retopolize to get a decent result.
first thing, set your minimum edge face to the number of edges of the polygon you are trying to troubleshoot. in your case 4. that gives you holes instead of ngons. that will give you a better read of the problem in complex problem areas.
next tune intersection tolerance, and other settings.
if that does not work try light intensity smooth curve strokes over the area. that gets most of them.
if there is still a problem use grab and tweak curve and smooth curve in the area.
as a last resort you can delete and redraw the problem curves.
has anybody run into frequent crashes for ptex? a lot of the times when i set up mesh for ptex painting, it will crash when I click done for ptex. Or ill run into the problem where I get seams when i step up to a higher subdivision. the amount of bugs i run into for ptex, just pretty much make texturing high rez in ptex workflow useless. it even has problems transfering textures from ptex to uv.
Yeah I think I know what you mean. I haven't done a lot of painting with Ptex, but when I did I remember having some crashes and a lot of lag. Can't really remember any specifics, but that was the 2012 version.
Or ill run into the problem where I get seams when i step up to a higher subdivision..
are you creating the ptex setup before or after you subdivided your mesh..?
ptex needs the higher levels to work like it should... [main problem with mari cause there are no subD levels]
the workflow should be...
subdivide your model
sculpt
go down to level0
create ptex
if you create the ptex first it cant consider the higher levels and the stretching on the surface...
if you crash during creation it could be bad geomentry... i havnt any ptex crash for a long time...
if you have an object that is crashing all the time please send it to the support...
To clarify my earlier post, I've been banging my head over this for a while.
I've been using Mudbox for PTEX vector displacements in my work flow for quite a while now, and I've tried everything - but success seems almost random.
Here is a run through of my workflow with some examples:
1. Model my base mesh, for this example I used Maya. Export as .OBJ, open with Mudbox.
2. Set PTEX parameters on base mesh. For this model I used 92 million texels, 9.6k equivalent.
3. Sculpt. This was my final mesh in Mudbox.
4. Extract my vector displacement map. These are my settings.
5. Export the new base mesh out as .obj, import that into Maya. I'm using RenderMan as my renderer.
6. Setup my mesh for PTEX, apply the shader and hook up my maps. Render.
Result: Perfect!
Now, following exactly the same work flow for my next model - this is my mudbox render compared to my Renderman Render:
I've tried exporting as .FBX, I've tried increasing my texel density, I've tried using a different vector space, I've gone crazy with the render samples in RenderMan... it's doing my head in!
I'd be interested to hear other peoples experiences / work-flow in regards to PTEX.
PS Hey forum. Long time lurker, first time poster.
how does your model look if you use the ptex in mudbox to displace the model...?
and have you tried to take a look at the vector ptex map aplied as diffuse texture..?
1. import lowres mesh...
2. subdivide it up to the same polycount as your highres...
3. sculpt using map
edit: dis does not work with vector maps... only normal dispmaps are working...
has anybody run into frequent crashes for ptex? a lot of the times when i set up mesh for ptex painting, it will crash when I click done for ptex. Or ill run into the problem where I get seams when i step up to a higher subdivision. the amount of bugs i run into for ptex, just pretty much make texturing high rez in ptex workflow useless. it even has problems transfering textures from ptex to uv.
in addition to oglu's suggestions you should watch your memory with ptex. the only time i have had crashes like that are when i tried to make a texture set that did not fit in memory. close your other applications etc. and for the seams, i don't have it in front of me atm but if i remember you can get that in the viewport if gigatex is managing your textures. read the docs on gigatex and adjust your vram paint buffer settings. you can also turn it off. that helps but uses more ram.
With a reyes renderer i reccomend exporting these settings:
absolute tangent space vector displacement as well as smooth both the source and the target models.
I had the same result using tangent space. However, It actually working using 'none' as the defined space in the ptx vector node, and object space on the shader displacement node.
...after exporting the map from mudbox in tangent space. :shifty:
in addition to oglu's suggestions you should watch your memory with ptex. the only time i have had crashes like that are when i tried to make a texture set that did not fit in memory. close your other applications etc. and for the seams, i don't have it in front of me atm but if i remember you can get that in the viewport if gigatex is managing your textures. read the docs on gigatex and adjust your vram paint buffer settings. you can also turn it off. that helps but uses more ram.
Yeah same. I find If I'm leaving a little room to move VRAM wise, it's a lot more stable. I tend to get crashes relatively often moving through paint history and stuff.
A titan card would be amazing for production work. 6GB VRAM!
i dont see the 8k size option in the create paint layer :S ,, i got an ati 6990 with 4gb ,, i only get the 4096 but not the "new" 8k option ,aynone haveing this issue or any solution ??
Haha yeah it would be about time they change their update policy. Sticking to 2012 until it changes ... (plus I suppose that the selecting/hiding bugs are still there anyways right ?)
Well, there was a lot of odd behaviors in 2012 and earlier, with objects being hidden but still selectable, brushes "hitting" hidden objects, and issues when exporting selected meshes ... I'll have to download the latest demo to see if that sort of things still happens.
last time i checked, there was still a bug that would select hidden objects if i did a select all. ideally, select all should only select objects that are not hidden. SP1 does not list any fix to this issue.
well, select all means select all so i agree with you on that.
however, it should only select all that is currently visible in viewport in my opinion.
other wise the "isolate" feature becomes partially useless.
i would bother to report bugs if i had faith in the bug reporting system. there have been many many bugs that i personally reported more than 2-3 times in the past and they weren't fixed in a span on 3 years straight.
anyways, simple issues like these should be caught in their internal bug testing if they have any. if they show a repeated pattern of ignoring bug reports then it should be their own priority to test bugs on their own because they are the ones loosing money not selling more copies due to such issues. i get by fine using older version of Mudbox for now and so does many others i believe...
there is a lot changing at AD... new tracking system, new developers,... and if you send some bugs to me i will take care of them and report them until they fixed it...
Since we are talking about Mudbox bugs, does anyone else here encounter the following problem :
Hi Guys,
When I export things out of Mudbox 2014 my geometry gets slightly jaggy.
I think what is going is that numbers of the vertex positions get rounded off to number with less decimals.
This is causing noticeable artifacts.
It happens when I export something from Mudbox 2014 as an .obj or .fbx
I found a workaround by using the connection to transfer it to Maya directly, and export to obj from there.
It's really anoying I tend to export obj's between Mudbox and Zbrush, but this bug creates massive amount of artifacts.
I feel strongly this artifacting happens at the export stage in mudbox, because the geometry gets these artifacts, in multiple packages I tested in Maya, Mudbox and Zbrush.
Objects transfered to maya first via the linking feature, and exported via as obj in maya, are clean when importing these in all above mentioned packages.
for me select all should select all... also hidden stuff...
and if you dont report the bug i cant help...
noone is reporting bugs it seems... no reports no fixes...
Not to get all angry but Luxology does this as well and it drives me insane. Developers see people on message boards talking about bugs or feature requests, but they won't do anything about it until someone submits an official report or request or whatever.
How about getting a little more proactive? We're not beta testers or QA - we're customers. Requiring paying customers to enter bugs and use the official system is basically a message that says, "We're not going to do anything about that until you fill out these TPS reports".
Arno : I can check to see if this happens in 2012 as well. Feel free to PM me your highres OBJ (one without artifacts of course) and I'll make a few export tests from there.
Replies
the second option is definitely nice but when it does not work on discontinuous meshes and majority if not all of my retopo work involves creating a lowpoly retopo on multiple highpoly meshes at once.
first decimate all your pieces so they are light weight then merge all the pieces and resurf.
you can then uv and pull maps as normal on your cage.
edit:
the decimation step is alway a good idea because it speeds up mesh gen and any other operations. then you can swap out with you highres at the end to pull maps.
as long as you just combine different mesh chunks while keeping the mesh elements disconnected topologically, you cannot resurface in mudbox.
that is the first thing i tried when i installed mudbox2014 trial.
makes me wonder if this workflow can adapted into the retopo feature so that the discontinuous mesh error doesn't appear.
anyways, topologically merging bigger highpoly meshes is not an option in most cases.
can you imagine topologically merging something like this :
http://cghub.com/images/view/313202/
the secondary point is that decimation and merging is not only always possible but usually the best approach. you can tune your overall polycount to a manageable size and merging decreases the amout or memory used and the amount of calculation needed as most of the algorithms work on front facing polygons. even if the tools are available to handle it i would not resurf on un-decimated hires and keep everything separate. and i whould have no problem decimateing and merging chunks of that model for resurf. in fact i have seen worse.
if you do some tests with that droid and decimate and merge chunks i think you will find it quite a solid technique once you get the hang of it.
edit:
the decimation in 2014 is better then the old decimation technique i was using in another package and its faster.
having more buildup is the correct behaviour. the stamp space is applied with the brush intensity that 'you' set so if you decrease the stamp space then you are going to get more stamps applied over the same area. if you wanted to be able to increase or decrease the stamp space to what ever you want and have the brush have the same intensity then the algorithm would have to take the average and adjust the intensity of each stamp to something other then what 'you' entered as the actual intensity value. i would never want that. i what the value that is input to be the actual value that is applied for each displacement stamp. you could end up with all kinds of crappy brush behaviour if the algorithm starts to decide what value to apply per stamp and disregard the actual value you put in the tool option. its much better to just manually adjust your stamp intensity to counter act the buildup. in some cases you can use buildup to get certain effects from stamps anyways which is a nice feature of how the brushes work now.
edit:
if anyone is interested in the basics of how to use VDM's then there is a great video on area that shows you the basics.
http://area.autodesk.com/blogs/craig/creating-hard-surface-stamps-outside-of-mudbox
its by no means the only use for VDM. they can do a lot more but it shows you the basics.
also, a predictable behavior is always preferred to an unpredictable one.
currently the spots seem to be limited to the number of times the brush registers on the surface depending on local space (screen space)
it might also be a performance limitation.
@ gavku, i am pretty sure that has been resolved.
and another similar bug was selected objects that you hide did not deselect after hiding.
both of these have been resolved in 2013 i think, at least it isnt there in 2014.
either way, you have to unhide all. hotkey for that is "u"
then deselect all just in case with "ctrl+d"
then try selecting all "ctrl+a" then try doing lvl up or lvl down "page up" or "page down"
np.
i am curious what version of Mudbox you are on. sound like it is a bug from 1.07 version.
Im a huge fan of the mudbox updates!
For Resurfacing with Curves. I find that there are a lot of times that i get holes in my mesh even tho i drew the lines to intersect as those points. My gripe is that it takes lots of tweaking to get a water tight mesh. And I missing something in my settings?
the only workaround i found so far is to patch the holes in mudbox and then run retopolize to get a decent result.
next tune intersection tolerance, and other settings.
if that does not work try light intensity smooth curve strokes over the area. that gets most of them.
if there is still a problem use grab and tweak curve and smooth curve in the area.
as a last resort you can delete and redraw the problem curves.
is there a easy way of selecting curves in viewport instead of cycling through the object list?
If you want to extract an accurate PTEX vector displacement good luck.
are you creating the ptex setup before or after you subdivided your mesh..?
ptex needs the higher levels to work like it should... [main problem with mari cause there are no subD levels]
the workflow should be...
subdivide your model
sculpt
go down to level0
create ptex
if you create the ptex first it cant consider the higher levels and the stretching on the surface...
if you crash during creation it could be bad geomentry... i havnt any ptex crash for a long time...
if you have an object that is crashing all the time please send it to the support...
I've been using Mudbox for PTEX vector displacements in my work flow for quite a while now, and I've tried everything - but success seems almost random.
Here is a run through of my workflow with some examples:
1. Model my base mesh, for this example I used Maya. Export as .OBJ, open with Mudbox.
2. Set PTEX parameters on base mesh. For this model I used 92 million texels, 9.6k equivalent.
3. Sculpt. This was my final mesh in Mudbox.
4. Extract my vector displacement map. These are my settings.
5. Export the new base mesh out as .obj, import that into Maya. I'm using RenderMan as my renderer.
6. Setup my mesh for PTEX, apply the shader and hook up my maps. Render.
Result: Perfect!
Now, following exactly the same work flow for my next model - this is my mudbox render compared to my Renderman Render:
I've tried exporting as .FBX, I've tried increasing my texel density, I've tried using a different vector space, I've gone crazy with the render samples in RenderMan... it's doing my head in!
I'd be interested to hear other peoples experiences / work-flow in regards to PTEX.
PS Hey forum. Long time lurker, first time poster.
and have you tried to take a look at the vector ptex map aplied as diffuse texture..?
1. import lowres mesh...
2. subdivide it up to the same polycount as your highres...
3. sculpt using map
edit: dis does not work with vector maps... only normal dispmaps are working...
EDIT: If I remember right, V-Ray doesn't actually support PTEX vectors does it?
With a reyes renderer i reccomend exporting these settings:
absolute tangent space vector displacement as well as smooth both the source and the target models.
in addition to oglu's suggestions you should watch your memory with ptex. the only time i have had crashes like that are when i tried to make a texture set that did not fit in memory. close your other applications etc. and for the seams, i don't have it in front of me atm but if i remember you can get that in the viewport if gigatex is managing your textures. read the docs on gigatex and adjust your vram paint buffer settings. you can also turn it off. that helps but uses more ram.
I had the same result using tangent space. However, It actually working using 'none' as the defined space in the ptx vector node, and object space on the shader displacement node.
...after exporting the map from mudbox in tangent space. :shifty:
Yeah same. I find If I'm leaving a little room to move VRAM wise, it's a lot more stable. I tend to get crashes relatively often moving through paint history and stuff.
A titan card would be amazing for production work. 6GB VRAM!
- New Symmetry Options for Retopology and for Existing Meshes
- New Caliper Tool - for measurements
[ame="
http://area.autodesk.com/products/features/extensionmudbox
or do i have to shell out another $915 for full license+subscription just for this small update even though i already have full license of 2011 ?
nah, i stopped reporting bugs long time ago.
besides, a major bug like that should not need public reporting. it should have been detected by internal QA.
and if you dont report the bug i cant help...
noone is reporting bugs it seems... no reports no fixes...
however, it should only select all that is currently visible in viewport in my opinion.
other wise the "isolate" feature becomes partially useless.
i would bother to report bugs if i had faith in the bug reporting system. there have been many many bugs that i personally reported more than 2-3 times in the past and they weren't fixed in a span on 3 years straight.
anyways, simple issues like these should be caught in their internal bug testing if they have any. if they show a repeated pattern of ignoring bug reports then it should be their own priority to test bugs on their own because they are the ones loosing money not selling more copies due to such issues. i get by fine using older version of Mudbox for now and so does many others i believe...
Hi Guys,
When I export things out of Mudbox 2014 my geometry gets slightly jaggy.
I think what is going is that numbers of the vertex positions get rounded off to number with less decimals.
This is causing noticeable artifacts.
It happens when I export something from Mudbox 2014 as an .obj or .fbx
I found a workaround by using the connection to transfer it to Maya directly, and export to obj from there.
It's really anoying I tend to export obj's between Mudbox and Zbrush, but this bug creates massive amount of artifacts.
I feel strongly this artifacting happens at the export stage in mudbox, because the geometry gets these artifacts, in multiple packages I tested in Maya, Mudbox and Zbrush.
Objects transfered to maya first via the linking feature, and exported via as obj in maya, are clean when importing these in all above mentioned packages.
I made a thread about it earlier here : http://www.polycount.com/forum/showthread.php?t=124289
How about getting a little more proactive? We're not beta testers or QA - we're customers. Requiring paying customers to enter bugs and use the official system is basically a message that says, "We're not going to do anything about that until you fill out these TPS reports".
thats the way it is...
and i dont like that system...