Impossible painting on muscle on a single mesh

Support & Help
, ,
1

What I’m trying to do: Paint on the maps of a muscle geometry using the AdonisFX Paint Tool.

What’s happening instead: On one single mesh out of 113 muscle geometries in the scene, the Paint Tool does not render paintable map values, so I cannot see where I am painting. With Smooth Mesh Preview OFF the mesh renders fully black. With Smooth Mesh Preview ON it renders flat green, as if no material were assigned. Outside the paint context the mesh displays its assigned material correctly in both modes, so the problem occurs only while the AdonisFX Paint Tool is active. All other 112 muscles in the same scene paint correctly.

Product: Adonis FX
Version and build number: 2.1.0.beta2
Operating system: Linux Linux Mint 22.3 (Ubuntu 24.04)
GPU: NVIDIA GeForce RTX 4070 Laptop, 8188 MB
Driver: NVIDIA 595.84, OpenGL 4.6
Viewport 2.0 rendering engine: OpenGLCoreProfileCompat
Software and version: Maya 2024.2.4

Steps to reproduce:

  1. Open the scene containing the horse muscle rig.
  2. Select the geometry “muscles_belly” (542 verts, 540 faces, 7 target slots, 2 attachment constraints, manifold).
  3. Open the AdonisFX Paint Tool and select any paintable attribute.
  4. The mesh renders black (Smooth Mesh Preview off) or flat green (Smooth Mesh Preview on).
  5. Repeat the same steps on “muscles_back” or “muscles_neck” these render correctly.

Any error messages or diagnostic files: No errors or warnings appear in the Script Editor when opening the Paint Tool on this mesh, with Show Stack Trace enabled.

Diagnostics already performed, ruling out the following causes:

  • Paintable map data is valid: weights, fibersMultiplier, envelopeWeights, mass and mushWeights all read min=1.000 max=1.000 across all 542 vertices. A black display is inconsistent with these values.
  • Geometry is clean: polyInfo reports no non-manifold vertices or edges.
  • Mesh density is not the factor: muscles_neck has 1155 verts (more than twice) and renders correctly.
  • Target array indices are contiguous [0..6] with no sparse gaps; all target maps return the full 542 values when read with explicit index slicing.
  • Naming convention is consistent and symmetric across the rig (verified with an audit script: 55/55 L/R pairs resolve correctly).
  • displayWeights and triggerDisplayWeights both read False; toggling them plus cmds.refresh(force=True) does not change the behaviour.

Possibly relevant:

  • Two attachment constraints on this mesh connect to AdnDebugLocator nodes (adnDebugShape1 / adnDebugShape2) at the world origin. This is one of the few structural differences from meshes that render correctly.
  • The same NVIDIA 595.84 driver has caused shader compilation issues with other applications on this system, so a shader fallback in Viewport 2.0 may be worth considering.

Questions:

  1. Is this a known issue in 2.1.0.beta2, or a regression from 2.0.x?
  2. Is there a way to force the Paint Tool to rebuild its display material for a given geometry?
  3. Are there any logging or diagnostic flags I can enable to capture more information from the tool?
  4. Is the Paint Tool display material sensitive to the Viewport 2.0 OpenGL profile on Linux?

I can provide an isolated version of the scene because its a project im working on. Thank you to very much!
Alessio

Horse_rig_AdonisFx_v9_to_fix.ma.zip (9.1 MB)

image
image1919×1200 480 KB

image
image1919×1200 464 KB

2

Hi Alessio,

Thanks for all the information you have provided.
We managed to reproduce the issue on your scene, but we still have to understand what may be causing the issue.
The good news is that by duplicating your geometry and recreating the muscle setup, makes it work as expected.

While we identify the source of the issue and develop a fix, let me give you a more detailed update.

We have confirmed the same behaviour on the muscles_belly geometry:

  • With Smooth Mesh Preview disabled, the paint visualization appears fully black.
  • With Smooth Mesh Preview enabled, the mesh appears flat green.
  • The issue occurs only while the AdonisFX Paint Tool is active.
  • The remaining muscle geometries behave correctly.

Regarding your questions:

  • Is this a known issue in 2.1.0.beta2, or a regression from 2.0.x? At this time, this is not a known issue, and we do not have evidence that it is a regression from AdonisFX 2.0.x. Your scene is the first case in which we have been able to reproduce this specific behaviour. We are currently investigating the underlying cause.
  • Is there a way to force the Paint Tool to rebuild its display material for a given geometry? Unfortunately, there is currently no user-facing command or option to force the Paint Tool to rebuild its display material for an individual geometry.
  • Are there any logging or diagnostic flags I can enable to capture more information from the tool? Unfortunately, there are no additional logging or diagnostic flags available for this part of the Paint Tool at the moment.
  • Is the Paint Tool display material sensitive to the Viewport 2.0 OpenGL profile on Linux? We have reproduced the issue on Windows as well. This allows us to discard, at least for this case, a Linux-specific Viewport 2.0 or OpenGL-profile limitation. It also makes the NVIDIA driver less likely to be the primary cause.

During our investigation, we found that duplicating the problematic mesh and recreating the muscle on the duplicated geometry makes the issue disappear. This works whether or not the history is deleted after duplication.

This suggests that the problem is related to something specific in the original geometry’s evaluation or construction-history path, rather than to the paintable map values or the visible topology itself. Our current intuition is therefore that some property produced by the live upstream history is affecting how the paint visualization is propagated to Smooth Mesh Preview.

We also found both muscles_bellyShapeOrig and muscles_bellyShapeOrig1 under the transform. The second intermediate shape appears to be disconnected, but removing it does not resolve the problem, so it does not seem to be the cause.

While we continue investigating, there are three available workarounds including the mentioned solution based on duplicating the geometry:

  1. Duplicate the problematic geometry, recreate the AdonisFX muscle on the duplicate, and replace the original muscle geometry with the duplicated version. In our tests, the Paint Tool visualization then works correctly.

  2. Delete the history of the problematic geometry and configure the AdnMuscle from scratch. In our tests, the Paint Tool visualization works in this case as well.

  3. Disable Smooth Mesh Preview while painting. This does not resolve the incorrect black visualization in the current scene, but it avoids the flat-green Smooth Mesh Preview display and may still be useful depending on the attribute being edited.

We also noticed two separate issues in the scene not related to the Paint Tool problem but worth mentioning:

  • There are two AdnDebug nodes in the scene. Normally, only one AdnDebug node should exist. We recommend deleting both nodes and then running AdonisFX > Debug > Refresh Debugger. Then make sure to rewind to reach the start frame of the simulation. This should recreate the expected single debugger instance and reconnect all solvers to it.
  • The AdnDebug nodes appear to be used as inputs for attachment constraints. This is not an expected setup. AdnDebug is intended only for displaying debug information and should not drive attachment constraints. It is expected to exist as a single instance at the world origin so that debug data is displayed correctly.

We are continuing to investigate the original geometry and its upstream evaluation graph to identify the exact condition that triggers the Paint Tool display failure. The isolated scene you provided has made this investigation possible, and we appreciate the time you took to prepare such a complete report.

Thank you.
Kind regards,

3

Hi Carlos,

Thank you for the detailed update and for investigating the issue so thoroughly.

I wanted to let you know that I tried the workaround you suggested: I duplicated the mesh, transferred all the various nodes onto the duplicated geometry, and it seems to work perfectly now! The Paint Tool visualization is finally behaving as expected.

I will clean up the scene, remove the extra debug node, and fix the constraint setup following your recommendations.

Thank you again for your time, the excellent support and the clear explanation.

All the best,

Alessio

1 Like