@MDavies, allright I'll tidy the list up a bit at home tonight. there are alot of things, and they are not all directly “baking” but related to it to get a good result and workflow.
hmm they did show up on a regular rop in 15.0.244.16, but I am downloading latest to verify.
My math knowledge when it comes to complex shader math is very limited so any example would be helpful
@MDavies, downloaded 15.0.282 to check the baking-specific planes, maybe I am missunderstanding, but it looks like Thickness and other baking planes are visable on this regular ROP:
@MagnusL3D: Yes, these are visible as VEX names in the drop-down menu. I will remove these as they don't make sense outside of baking tasks. Thanks for spotting this
@MagnusL3D: Here is an example of how to output thickness from a shader. The VOP is copied directly from the Bake Shader, so you should get similar output.
@MDavies, btw, as promised here is my “list”. Now it's mostly random thoughts and alot flow outside the “core” baking functionality but it is things I belive would enhance and sometimes are crucial to get the whole “automate massive amount of baked assets”-pipe going. But that pipe might in itself be just a dream but anyway here goes:
“Short Term” ————– - Correct Colorspace on TGA etc (Linear(SRGB))
- I am not sure having some channels in one tab and some others in another tab is the best solution. It feels a bit confusing and since there is already so manny tabs, it is confusing to find them both.
- Even though the filter python script is great it feels like it could be alot more artist friendly to just use “Extra Image Planes” feature with + and easily naming your outputs the way you want.
- Neither FBX or HE assets can be fully automated with all texture channels (for Unreal atleast). - The FBX limitation in Unreal is limited to Diffuse, Specular, Bump and Emmisve - HE assets can only do Diffuse and Normal
- If you use HE assets you have to use .rat to get more than 1 textuer channel. Where Normal channel is ‘N’ while the baking outputs ‘Nt’ - Would be nice if it supported - Diffuse - Normal - Specular - Roughness - Metallic - Emmisive color
“Long Term” ————– - UV, only 100% guarantee for no overlaps right now is to use UV-Unwrap which causes tons of UV-islands. - Some sort of hybrid soft UV-unwrap to keep small islands within large islands connected and then UV-flatten wold help a great deal but not a final solution. I did a test in SOPs with this and got the UV islands down from 500 to 200 but still to much, biggest issue was that I dont know how to “move and sew” small islands to the large one.
- Polyreduce, generates strange very strange triangulation at times, a new and improved way of reducing polys would be helpful.
- More noise patterns shipping with houdini for more interesting “procedural VDB sculpting”
- SideFX supported version of something like Eetu's grit shader VOP, and other shader VOP's to generate grit and dirt easily.
I have modified the ‘filter.py’ file so it renames the files the way I like it, and also removes the .rat file for a clean output. I might or might not look into inserting the .MTL .OBJ fix into this aswell but for now atleast it gives in my mind a nice output, specially if you are doing alot of assets, since now they will end up besides each other.
The output looks like the attached image and works if you are using the ‘$HIP/name_test/$HIPNAME.$F2.rat’ and ‘$HIP/name_test/$HIPNAME.$F2.obj’ for your texture and object output.
I also set it up with more standard names like “normal”, “diffuse” etc instead of our internal names, so it is useful for others.
@MagnusL3D: Thanks for passing along this script. It will be useful for others to see the automated workflow you have set up.
In terms of TGA output, I've verified that this works (see attached). In your case was it mainly the color space that was the issue (ie. linear vs. sRGB)?
Well perhaps I shouldnt say linear vs. sRGB, perhaps I should say..The diffuse looks waaay to dark in Unreal (and Photoshop), like it is almost black. The other channels seem to work fine. It also looks almost black in picasa and photoshop.
My work around for that was to put down a colorcorrect vop in the shader feeding the diff_clr and setting the gamma to 2.2. But it feels like it is loosing contrast/color when doing it like that (could be wrong).
@MDavies: BTW, regarding the thickness rendering all black, figured it out that it was the “scope”, “self” line that needed to be set to the actual name of the mesh so “scope”, “mesh_name”. self didnt work for some reason, resulting in a black render.
Personally, I think the most user-friendly setup would be the following:
1. Overall I think the main categories should be: Output Rendering
In Output goes every parameter that concerns what gets rendered and where the output is saved and what the output will be named. In Rendering goes every parameter concerning how things get rendered.
2. The first parameter tab in Output should be one parameter tab for activating available image planes (This would be a combination of Image Planes Combined with the Extra Image Planes, but without the Extract stuff)
3. The seccond parameter tab in Output should be one parameter tab for the image plane export and naming. (Let's name it the “image naming tab”). The Output Picture parameter should be altered for consistency. It should only be the basic output path.
The image naming tab focuses entirely on what is output and how it is named. Here you put the Extract stuff. Here you should also have the option to use a script or a parameter list for naming. To this end, the should be a base-name string parameter and every image plane should have a separate script-able string parameter. Similar to the first suggestion of MagnusL3D, you should be able to define a relative path (starting from the location described in the Output Picture parameter), the name (base-name string+ suffix with variables) and file-type of the output, as well as a possible image plane remapping. - You might ask: Why use a parameter for each image plane when you have a script for that? I think it is important, because it is in line with what users expect from modern 3D programs. It is overall faster to edit and has a far lower access tesh-hold than a script.
For simplicity, the vex variable planes should have the “naming and location string parameter” as a default part of their setup.