I like the look of the new forum, but I'm not a big fan of how your version of NodeBB hijacks the browser's search when using CTRL+F. It instead uses the webpage's search function, which in itself adds 2 additional steps/clicks to get to the word(s) I was searching for.
Just a small piece of feedback though, as everything else feels like a major upgrade!
Whoopsies. I had forgotten this one setting:
settings.SetBool(BAKE_TEX_NORMAL_USE_RAYCAST, true);
It works as expected now.
Apologies!
This matter is now resolved.
Thinking that the problem stemmed from the lack of color profile, I attempted to add the BAKE_TEX_COLORPROFILE enum to my settings, but I was unable to do so without it throwing an error upon the building of my solution.
My updated settings:
AutoAlloc<ColorProfile> colorProfile;
if (!colorProfile || !colorProfile->GetDefaultSRGB())
{
return maxon::UnexpectedError(MAXON_SOURCE_LOCATION, "Failed to allocate or initialize the color profile."_s);
}
// Setup bake settings
BaseContainer settings;
// ...other settings removed for brevity...
settings.SetData(BAKE_TEX_COLORPROFILE, GeData(colorProfile));
Unfortunately, the additional line above (i.e. BAKE_TEX_COLORPROFILE) throws the following errors upon building my solution:
BaseContainer::SetData: no overloaded function takes 1 arguments<function-style-cast>: cannot convert from AutoAlloc<ColorProfile> to GeDataI've been "fighting" with the SDK for the past hour while extensively reading the documentation, but I have yet to find a solution.
If my problem has nothing to do with the color profile, I guess that would also be good to know! 
Thank you very much as always.
Hey guys,
I'm trying to understand why the normal map baked (in object space) by the Bake Material tag is different from the one that is baked by the the SDK (using the InitBakeTexture() and BakeTexture() functions) when they are seemingly both given the same parameters.
In both cases (the Bake Material tag and the SDK functions), these are my settings:
The Base Material tag gives me this:
While the InitBakeTexture() and BakeTexture() functions give me this:
Unless I am wrong, the result yielded by the Bake Material tag seems to be the most accurate and favorable one (in terms of color spectrum). Am I wrong?
Here is an excerpt of my C++ code:
BaseContainer settings;
settings.SetInt32(BAKE_TEX_WIDTH, 1024);
settings.SetInt32(BAKE_TEX_HEIGHT, 1024);
settings.SetInt32(BAKE_TEX_PIXELBORDER, 0);
settings.SetBool(BAKE_TEX_CONTINUE_UV, true);
settings.SetBool(BAKE_TEX_USE_PHONG_TAG, true);
settings.SetVector(BAKE_TEX_FILL_COLOR, Vector(0.0));
settings.SetBool(BAKE_TEX_NORMAL, true);
settings.SetBool(BAKE_TEX_NORMAL_METHOD_OBJECT, true);
BAKE_TEX_ERR err;
BaseDocument* bakeDoc = InitBakeTexture(doc, (TextureTag*)textureTag, (UVWTag*)uvwTag, nullptr, settings, &err, nullptr);
// Check if initialization was successful
if (err != BAKE_TEX_ERR::NONE)
return maxon::UnexpectedError(MAXON_SOURCE_LOCATION, "Failed to initialize baking of the normal map."_s);
// Prepare bitmap for baking
MultipassBitmap* normalMap = MultipassBitmap::Alloc(1024, 1024, COLORMODE::RGBw);
if (!normalMap)
return maxon::UnexpectedError(MAXON_SOURCE_LOCATION, "Could not allocate normal map."_s);
// Perform the bake for the normal map
BakeTexture(bakeDoc, settings, normalMap, nullptr, nullptr, nullptr);
// File path of the normal map
maxon::Url urlNormalMapResult{ "file:///C:/filepath/normal_map.png"_s };
normalMap->Save(MaxonConvert(urlNormalMapResult), FILTER_PNG, nullptr, SAVEBIT::NONE);
Note: I am currently assigning the color mode RGBw to normalMap. I have experimented a lot in that area and I have not been able to find any other COLORMODE or any other setting/enum for that matter that would get me closer to the normal map baked by the Base Material tag.
Any insight/guidance would be massively appreciated as always.
Thank you so much!
Thanks a lot for confirming my doubts, @i_mazlov.
I'll find a compromise, but I can't help but express how great it would be if BodyPaint exposed such functionality.
The Brush tool and its filters (such as "Smudge") can't be replicated with a simple bitmap texture, and gaining access to it (mind you, in the context where the Paint brush can be programmatically moved/dragged across the UV space) would open the door to so many creative and useful applications.
Of course, I'm sure you are already aware of all of this. This is just me casting a single vote for a potential addition of the Brush tool to the SDK in the future.
Thanks for everything! 
I thought I had exhausted the search keywords before posting this, but upon searching this forum again, I found this thread, which I think answers my question.
Unless proven otherwise, I will consider my intended task to be impossible. A bummer, but I'll try to find another way or give up on the task altogether. All good!
Hey guys!
I am simply looking for some guidance on how I would go about programmatically drawing with BodyPaint's Brush tool in UV space (if even possible).
I know how to use the SDK to configure the Brush tool's settings, but after scouring the C++ documentation on the BodyPaint module and carefully reading through the Painting repo example and, lastly, experimenting with some bits of code (to no avail whatsoever), I'm afraid to admit that I am not sure where to even start.
For example, I would like to have the Brush tool, with its specific brush settings, to draw from the UV coordinates (0,0,0) to (0.5,0.5,0), just as if the user dragged their mouse between both coordinates in the viewport with the Brush tool.
Apologies in advance if I missed something obvious in the SDK documentation.
Any guidance would be immensely appreciated.
Thank you very much!
@ferdinand Oh wow! Thank you so much for letting me know about Keenan Crane, as I was not familiar with him. I am in awe of the exhaustive list of tools he and his lab have published.
The Globally Optimal Direction Fields paper seems indeed to be exactly what I am looking for. I was also surprised to see that I had already skimmed the Youtube video of the paper back in December.
Thank you so much @ferdinand for this invaluable piece of information. Time to dive in!
Cheers!
First off, thank you so very kindly @ferdinand. I have been spending the first half of today experimenting with your code snippet (after translating it to C++) and I can attest to it working as expected, which was absolutely delightful. Thank you again for your assistance with this.
After further investigation and exploration, I must admit to feeling quite... silly (to put it nicely) and I must apologize for a healthy dose of profound foolishness on my side.
Somehow, I thought that the orientation of clones of a Cloner whose "Distribution" setting was set to "Surface" with its "Up Vector" setting set to "None" would be almost identical to the orientation of the voxels of a Volume Builder whose "Volume Type" was set to "Vector" while having its voxels orientation be influenced by a "Solid Layer" in a "Group Field" with the "Direction" turned on (and set to a specific vector direction, Z+ in this case). Please see the screenshot below for a better understanding of what I mean:
I have also attached the project file of the screenshot included above to this message, which you can find here: figure-vector-field-01.c4d
I feel silly, because... I tested @ferdinand 's approach on different meshes (like the Landscape Primitive) and the orientation of the Pyramids graciously provided by Ferdinand's code VS the orientation of the Voxels from the Volume Builder (with a Group Field and Solid Layer) was vastly different as expected (or rather, as I should have expected but didn't).
This now strays away from the original question and leads me consider making a new thread, which I shall do after I first exhaust every potential solution my skillset can offer. I will first dive back into the code generously offered by @ferdinand back in December (here), which should hopefully lead me in the right direction (pun unintended).
I thank you all once again for your very thorough, generous and invaluable assistance 
@i_mazlov Hey Ilia,
I sincerely can't thank you enough for leading me down the right path. Having a tangential plane from the polygon normals mixed in with a direction that depends on polygon vertices order is an approach that never occurred to me. I wish I had asked my question sooner, as I have spent the last 2 weeks exploring many different and more intricate approaches without any success, so you can only imagine how grateful I am for your assistance today.
After implementing your recommended approach, I noticed the following: while the clones (red Pyramid primitive objects as illustrated in the screenshot of my previous message) that are situated on the front-side and left-side facing polygons of my Object are oriented in the desired fashion (i.e. just like the Cloner object with a "Up Vector" set to "None"), the clones situated on the back-side and right-side facing polygons of my Object are oriented in the polar opposite direction of where I would like them to "point" towards (i.e. so the opposite of the desired direction). I presume that this is due to the fact that the normals values were calculated on the Object's local coordinates. For example, a polygon situated at the front of the Object (let's say, the middle chest part of the Object) will have its normals be (0;0.1;-1), while a polygon situated on the complete opposite side of the Object (i.e. its middle back) will have its normals value be (0;0.1;1).
As you can observe in the screenshot from my previous message, the clones (Pyramid primitives) are all facing upwards on the (for example) right thigh of the Object, whether they are in front, on the back, left or right side of said thigh. Same thing for the arms, where they are all uniformly pointing in either the right or left direction (discarding the wrists or elbows of course).
My question is: with the current approach of having a tangential plane from the polygon normals mixed in with a direction that depends on polygon vertices order, would it be possible to replicate the uniform direction of the clones as illustrated in the screenshot, regardless of the side they are facing on the Object?
I have attempted several things today, such as adjusting the vertex order based on normal direction, introducing a directional bias in world space and, lastly, using world space normals for consistency. All to say, nothing has worked so far. I kept questioning whether I was ever on the right path or if I was over-complicating things when the solution (which escapes me) might be much simpler.
Once again, thank you very, very much for your guidance and assistance. It has already been extremely valuable. I'm very grateful!
Hey guys,
In Cinema 4D, when setting a Cloner's mode to "Object" and "Distribution" mode to "Surface" (while leaving the "Up Vector" setting to "None"), the Cloner's clones are orientated in such a way that they follow the curvature of the geometry of the source Object while still seemingly being orientated in a "continuous flow", where they are not abruptly changing their orientation like they would if they were exclusively following the Object's normals in local/object space. In fact, their "continuous orientation" almost makes it seem that their orientation is also taking into account global/world space?
While I know this is a very basic setup, I am still going to include a screenshot to leave no room for interpretation as to what I am referring to:
My question is: in plain english, in the code of Cinema 4D's Cloner, how is this achieved? Is there a detection of adjacent polygons and then an averaging of normals?...or is an invisible Vector Field generated that dictates the orientation of the clones? As you can tell, I am quite lost and in need of guidance, as I am looking to loosely replicate some of the behavior of the Cloner object (in this specific mode and with these specific settings) within my plugin. While my approach will be more abstract, it still needs to get the fundamentals of this orientation logic correct.
Any insight would be greatly, greatly appreciated.
Thank you so much!