I am wondering if there is an easy way to combine ptex textures so that they can share the same shader/shadingEngine in maya vray 3.4.
I understand there is a way using the multisubtex texture node via object and materialIds. My issue is that with our current setup I dont think this is possible. Somebody else may be able to see around this so I’ll explain a bit what we are trying to do.
I am baking ptex elements across multiple objects that share a common shader. It is important that the ‘baked’ ptex elements and non-baked shader share a common materialId - therefore we cannot distribute materials via the multisubtex element and materialId.
In lighting scenes we auto-generate vrayobjectproperty nodes per asset - so all renderable mesh share a common vrayobjectproperty node per reference. Usually the vrayobjectproperte node has its objectId override turned on with a unique value that is used with the objectID render element to separate mattes for the individual assets in compositing. Therefore with this setup we cannot use objectIds to distribute materials via the multisubtex element.
Therefore I am wondering how/if I can otherwise combine ptex elements.
If I understand you correctly you want to use multiple ptex textures in one shader, and have each one apply to a different geometry?
You don’t need object ids for that. You can use VrayUserScalar and assign a custom user value to each shape, then use a condition node, where in first term you plugin user scalar and in second term you put the number which equals to the number of the geometry which you want to apply your ptex to. This in theory should apply ptex to those specific meshes.
Thank you. That is very helpful and does answer my question.
On an unrelated note - Baking out ptex textures for hair (geometry hair), im noticing the alpha textures arent transferring across to the ptex. Has anyone else experienced this issue?
Edit: So the issue looks to be that the vraymultisubtext doesnt seem to have an alpha out slot, only outcolor, therefore it doesnt seem to work if i plug the outcolor in the opacity map of a vraymaterial.
Correct. The ptex does have an outalpha - the multisubtex does not.
It wasnt a huge deal as the issue went once i switched over to the VrayUserScalar approach mentioned below. Unfortunately though it does look as though the out alpha still isnt being correct applied for whatever reason. It may be an issue with the subdivisions or something related. There are many layers of polygon hair with transparency over the top of one another. Im trying to experiment with the settings ( such as offset ) to see if it helps resolve the issue.
yeah you’d have to post a small example to be sure. But from the top of my head, condition node (if you are using it) only passes RGB not A. So you’d have to duplicate the setup for A again.
ATM it (the resulting ptex) is just rendering black ifi bake with subdivisions enabled on. The mesh is subdivided with OSD (which the docs say should be fine). Baking without subdivisions on looks to work correctly - but because the mesh intersects when not smoothed is problematic and ends up with black patches accross.
Edit: aha! the issue was visibility test rays. Disabled this attribute and now the ptex exports perfectly!
I understand and can implement all that. What is the best way of merging the conditions together?
layered texture? ATM i have the conditions false outputting black and have them all connected to a layered shader with the idents. set to add. Is there a better/more efficient way?
Edit: Now that ive expanded it out to write multiple parts of the mesh i’m noticing alot of @mesh.ptx appended to the end which is a little confusing when there is multiple of each mesh
fair enough.
Working in a pipeline where the UV state of assets cannot be guaranteed. Some have overlapping components (such has hair ) and some no uvs at all.
At the moment the script iterates over all of the mesh, bakes individually and sets up all the shaders etc. The output generated looks great but the ptex baking itself is pretty slow though..
FYI: There is no need to use conditionals, because V-Ray supports user attributes in the names of the ptex file nodes.
You can just create user attributes on the instance nodes which can be used to select the textures.
Thanks Petrov. This will simplify my script setup considerably. Well worth the additional time to go back and change the conditionals setup.
My only issue now is that i cant predict what the ptex file will be called - given that vrays ptex baking tool appends @mesh1 or @mesh6 etc to the end of the files. If it were only going to write one that wouldnt be a problem Id just listdir it and find the mesh name in the directory, but often it writes multiple and I cant seem to find anything in the docs or google that explains it.
I should also note that although the docs say that vray osd subdivs are fine for baking, they don’t ever seem to work and always end up with a garbled tex output. Ive been baking with them off for that reason which is producing decent results. But if there is a method to using them with baking to ptex that would be great to know.
“PTex files are strongly connected to the topology of an objects’s mesh. Therefore any modification which change the topology will break the rendering of the PTex texture. If you want to smooth the object, you can use V-Rays own subdivision/displacement.”
I could be misinterpreting the ‘vrays own subdivision/displacement’ but from that i inferred vrays osd would be fine.
Yes, you’re misinterpreting it.
Our own subdivision/displacement algorithm works with PTex just fine.
See here how to enable them: Chaos Docs
I’m not sure if PTex+OpenSubdiv is know limitation, bug or impossible to do.
But I can confirm that it doesn’t work at the moment. I’ll see if I can learn something about this matter.
As a workaround I just discovered i get better results (than having sub divs off entirely) by switching to vray subdivs, baking and then switching back to vray osd subdivs ( the osd component is not optional for this pipeline ).
Any insight into the @mesh being appended to the filenames at bake time?
About the @meshN thing: those are part of the internal name of the object and there is unfortunately no way to predict them other than knowing which (logically indexed) mesh in the scene it is. We might strip them out in the next service pack, since I don’t know of any reason to keep the internal tags as part of the filename.
