问题标签 [physx]

我现在正在调查 PhysX，我一直坚持序列化。当我尝试序列化关节时，反序列化失败并出现错误：

但如果没有关节，它可以正常工作并反序列化所有对象。正确序列化关节是否需要任何其他操作？代码有序列化部分：

反序列化：

我有一个默认的空白 Windows 商店应用程序，添加了以下代码：

我的 Linker->Input->Additional Dependencies 设置中有以下内容：

我添加了包含目录：MyPhysXPath\Include

库位于此目录中：MyPhysXPath\Lib\win8arm

如果我将该路径添加到“库目录”设置，我会收到 PxDefaultErrorCallback 的 LNK2019 错误。

如果我将该路径添加到“库 WinRT 目录”设置，我会收到 PhysX3CHECKED_arm.lib 的 LNK1104 错误。

如果我将该路径添加到两个设置中，我会收到 LNK2019 错误。

通过链接到 win32 库可以很容易地构建项目，但它不会运行。

我的问题是：

1. 我需要链接到PhysX SDK的winRT版本而不是Windows 8 PC Metro应用程序的x86版本，我对吗？
2. 假设这是正确的，链接到 WinRT 库的正确方法是什么？

谢谢你！

我仍在研究用于模拟流体的物理系统。我重写了我的应用程序以使用 PhysX 3.3.0 并且更加客观，现在我有一个问题，我无法在一两个星期内解决。

这是我对 PhysX Context 的启蒙：

并启动 physX 场景，但即使是空场景也会出现问题：

如果注释了#ifdef PX_WINDOWS 中的代码，则一切正常。流体按应有的方式流动。但是当我尝试使用我的 GPU 时，应用程序在第一次 fetchResult() 调用时冻结（simulate() 方法永远不会完成它的工作）。我没有错误日志，它只是冻结。无论是 DEBUG 还是 RELEASE，以及它是 32 还是 64 版本，都会发生这种情况。

我有一个 GeForce 560Ti。我使用 Physx SDK 3.3.0。我链接（例如在 win64 调试版本上）与：

opengl32.lib glew32.lib glfw3.lib PhysX3DEBUG_x64.lib PhysX3CommonDEBUG_x64.lib PxTaskDEBUG.lib PhysX3ExtensionsDEBUG.lib PhysXProfileSDKDEBUG.lib

使用：

nvToolsExt64_1.dll PhysX3XHECKED_x64.dll PhysX3CommonCHECKED_x64.dll PhysX3GpuCHECKED_x64.dll PhysX3GpuDEBUG_x64.dll

我尝试使用不同版本的 .libs 并添加应用程序所需的 .dlls，但每组最终都会在 fetchResult() 上冻结。

我不知道在哪里寻找错误。一切看起来都很好。我会很感激任何帮助！

如何在 PhysX.net 中向我的 Actor/ShapeDesc 添加纹理？

我正在使用 XNA 和 PhysX.NET。

我有场景，一切都设置好了，一切正常，但我的游戏引擎在 Wireframe 模式下看起来不太好，你知道我的意思。

再次感谢你！

Draw()方法：

而且.. Int32ToColor()：

我意识到这可能不是询问有关 PhysX 问题的理想场所，但我已经在 PhysX 官方论坛以及 gamedev.net 上进行过尝试，但我已经好几周没有收到任何回复了，所以我我不确定我可以去哪里寻求帮助。也许这里有人有想法。

我的问题如下：

我的 PxRigidDynamic 演员与其他演员相交，我不知道为什么。它们之间仍然存在碰撞，但刚性动态略微穿过它们并被“推”回来。这是它在游戏中/在 PVD ​​中的视频：

http://youtu.be/X0oyDtCTsuQ

盒子是一个 PxRigidDynamic 演员。播放器是一个 PxCapsuleController。所有其他演员都是 PxRigidStatic。

禁用或启用 CCD 似乎没有什么区别。（CCD应该只影响高速物体，所以我怀疑这就是原因）

控制器和静态演员之间的碰撞很好，所以我不明白为什么刚性动态会有任何不同的行为。

我正在使用 PhysX-3.3.0_Beta-2 (16402319)

我正在尝试为 PhysX 应用程序中的物理模拟定义一个时间步长，以便物理在所有机器上以相同的速度运行。我希望物理以 60FPS 的速度更新，所以每次更新应该有 1/60 秒的增量时间。

我的应用程序必须使用 GLUT。目前，我的循环设置如下。

空闲功能：

在这种情况下，帧速率并不重要——只有我的物理更新速度才是真正重要的。

我的渲染函数包含以下内容：

在哪里：

但是，这会导致一些非常缓慢的更新，因为 deltaTime 在大多数循环上似乎等于 0（这实际上是不可能的......）我已经尝试将我的 deltaTime 计算移动到我的渲染函数的底部，因为我认为空闲回调可能被调用太频繁，但这并没有解决问题。有什么想法我在这里做错了吗？

根据我的观察，havok 在刚性模拟方面比 Physx 做得好得多，尤其是他们的新 Havok Physics 2013。

我对最先进的物理引擎的工作原理不是很熟悉，但是仅通过测试我无法获得非常准确的测试结果。

例如，PhysX 似乎仍然故意削弱 CPU 性能。我的结果显示，当同时交互刚体超过一定数量（范围从 1024 到 8096 个盒子）时，它的性能会沿着非常不自然的陡峭曲线下降，并且当它与 Bullet 的性能匹配时会停止垂直下降。然而，我测试过的许多其他引擎随着场景复杂度的增加而相对线性地扩展。

如果我想测量真实世界的场景，例如游戏、游戏引擎甚至 CG 制作，情况会更糟。

毫无疑问，GPU 比 CPU 处理粒子物理要好得多，所以我想把这个讨论限制在刚体和软体（包括布料）模拟上。

那么，物理模拟在 GPU 上真的更快吗？如果是，是多少？

因此，我正在尝试从 Qt Creator 中的 HelloWorldRender 片段编译代码。我想做的只是单步调试调试器中的代码并弄乱它，这样我就可以理解如何使用它。

然而，问题是当我尝试构建我的项目时，我遇到了大量的链接器错误（达到的最大错误数超过 1400）。我几乎可以肯定原因是由于指定了库的顺序。

值得一提的关键点

• 对于那些不熟悉 QMake 的人：请注意，GCC 用于编译它；QMake 中指定的链接器顺序与 GCC 是一对一的。

• 我已经尝试了各种不同的链接顺序，其中一些甚至涉及重复列表中的某些库......我能够将错误计数减少到最接近的是 150 左右。

• HelloWorldSnippet ( ) 所需的一个库（libRenderSnippetCHECKED.a不是 SDK 的一部分）已经编译，没有任何问题，并在要链接的库列表中指定。

• 许多这个项目信息（链接库，定义）实际上是从为这个片段搜索 Makefile 并破译（显然）自动生成的代码行中获取的。

• PhysX 的文档是……稀疏的，尽管它似乎是一个流行的 API。我还没有找到任何真正描述如何在 Linux 环境中运行它的东西（公平地说，这个版本大约有 2 个月的历史）。

• 使用的发行版是 Ubuntu 13.10。在 x86_64 架构上编译，使用 Optimus 设置。

除了我的项目文件之外，为了方便起见，我还包含了未修改的 HelloWorld 文件。

。轮廓

片段HelloWorld.cpp

片段HelloWorldRender.cpp

我需要在 PhysX 3.2 中制作一个类似 NULL 的刚体。非碰撞的 - 仅作为锚点。有什么办法吗？我只需要它来解决一些关节组合。提前致谢

默认情况下，PhysX 中的运动学 Actor 会简单地将控制器推开或忽略它们：

http://youtu.be/2bJDOjFIrRI

对于电梯或自动扶梯之类的东西，这显然不是理想的行为。我不确定如何将控制器实际“粘贴”到平台上以确保播放器不会掉落。

在每个模拟步骤移动控制器时，我尝试将平台的运动目标偏移添加到位移矢量，但这并不能阻止运动演员的“推动”，而且也不是很准确。

这通常是如何实现的？文档提到使用障碍物移动平台，但我看不出在这种情况下会有什么帮助。

我正在使用 PhysX 3.3.0。