Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

In this Discussion

Tags in this Discussion

NxApexScene::fetchResult() assert dstPosition[vertexIndex].isFinite()
  • Vote Up1Vote Down Marson Mao
    Posts: 10
    I got this assert in NxApexScene::fetchResult()

    dstPosition[vertexIndex].isFinite()

    What is the cause of this?
    Thanks!
  • 9 Comments sorted by
  • Vote Up1Vote Down Philipp Hatt
    Posts: 11 Accepted Answer
    Hi Marson Mao

    This assert is part of the clothing verification (but I guess you already knew that). It is only present in debug builds, but it is a good catch. This usually means that something with the simulation went terribly wrong, and then when trying to bind the render-mesh to the simulation mesh, this verification kicks in a safeguard.

    When you run a release build (without this assert) you could turn on debug rendering for the cloth to see the simulated positions (it's called VISUALIZE_CLOTHING_PHYSICS_MESH_WIRE), and if the simulation mesh gets to a bad state indeed, then you have a first clue.

    It is also possible that you provided invalid input in the NxClothingActor::updateState call (a matrix that has inf or nan values maybe?). you can check this by turning on the debug rendering for the skinned positions (VISUALIZE_CLOTHING_SKINNED_POSITIONS) and see check if they are where you would expect them (little crosses in blue or gray shades). If you don't see them at all, it is another hint that the matrices might contain wrong data and they ended up at infinity.

    Best
    --Philipp
  • Vote Up1Vote Down Philipp Hatt
    Posts: 11
    I hope the info was useful in helping you find the culprit.

    I am not sure we need to add an ASSERT info document, the asserts are only for people who already have a source distribution, and therefore could take a look at the code anyways.

    I will however try to add some comments to the code where the assert is to clarify what went wrong when it got hit.

    In any case, asserts should always be non-fatal if they hit. Some will produce an additional message on the error stream, others will be silently ignored. In your case you will also notice that something went wrong through the render API, the NxUserRenderVertexBuffer::writeBuffer() call will contain positions that are non-finite.

    --Philipp
  • Vote Up1Vote Down Philipp Hatt
    Posts: 11
    That's why I suggested running Apex in release mode (no asserts there) and your application in debug. That way you can turn on the different debug rendering options and maybe see what's going on. You could for example implement your own isFinite assert inside your writeBuffer implementation to check for valid data.

    --Philipp
  • Vote Up0Vote Down Marson Mao
    Posts: 10
    omg this is extremely helpful, thanks in millions!
    I'll go for some research using these hints.

    By the way, is there anything like "assert info document" available?
    Like the information you provided?
    The document should list all asserts and the corresponding info.
    So that I can check the reason myself, thanks! :)
  • Vote Up0Vote Down Marson Mao
    Posts: 10
    I see. I am using APEX sdk 1.0, and the assert happens in DLL calls (i.e. fetchResult()), so I cant see the exact code for that assert. That's why I am looking for some documents :p

    And becuase the assert stops me from running debug mode DLL, therefore I post the question hoping to solve that problem.
    But I guess the writeBuffer() is ok? Because I run the program with no problem until fetchResult() call in onTickPostRender(). (Using SimpleClothing's code as base).
    I got the assert in the first frame drawing, so I have no chance to see what was drawn in this frame.
  • Vote Up0Vote Down Marson Mao
    Posts: 10
    Ok, I think I got your point.
    But 1 last question, how to run Apex in release and my app in debug at the same time?
    I thought all projects in a solution can only use the same mode?
    Like you can switch modes by the list next to the little green triangle for Run (supposed using Visual Studio 2010), but there could be only 1 mode selected?
  • Vote Up0Vote Down Philipp Hatt
    Posts: 11
    There can only be one mode selected, but if you set the APEX lib in the "additional library dependencies" tab (instead of using build dependencies) you can use the debug APEX lib with your release builds, and the release APEX build with your debug builds (and possibly other combinations as well).

    The problem with these setups usually only come from the c-runtime lib that is used. But since the Apex API is completely free of c-runtime classes (we don't pass std::vectors or similar through the API) it doesn't really matter if the APEX dlls use a different c-runtime than your application.

    hope this helps
    --Philipp
  • Vote Up0Vote Down Marson Mao
    Posts: 10
    Ok I got it, I am doing exactly the way you suggest.
    I switch to debug mode by modifying the Linker->Input->Additional Dependencies setting from ApexFramework_x86.lib to ApexFrameworkDEBUG_x86.lib.
    Normally I am running with release build lib. :]
  • Vote Up0Vote Down Philipp Hatt
    Posts: 11
    Great to hear it works, though I did mean to do it the other way around.

    In your debug build you should still link to ApexFramework_86.dll (instead of the debug one).
    This will give you better perf in debug builds, and no asserts

    --Philipp
Add a Comment