Hi, When I use the mesh you linked and the source code you provided, each frame takes about 33ms on my GTX 1660.
If the mesh will not be deforming during the simulation, set the visual model accordingly so that the vertices do not get checked/updated during the simulation: imported->GetVisualShape(0)->SetMutable(false); For me, this brings the average frame time from 33 ms down to about 6 ms. This would make sense with you seeing that the time was not impacted by camera resolution. If the rendering is the bottleneck, then increasing the resolution will increase the render time. When timing, I removed the call to realtime_timer.Spin(step_size); as it will spin when the simulation is faster that real time, masking the true render time. Let me know if you still see slow render times after this change. Best, Asher On Thursday, December 8, 2022 at 2:54:44 PM UTC-5 [email protected] wrote: > Thank you for your reply. > Unfortunately I am not able to share this particular mesh, but the > performance problem is not unique to it. I tried some high poly meshes I > found online (for example this > https://sketchfab.com/3d-models/car-model-blender-2be4c41ccc774fc79f3e598e0091e3b9), > > and saw the same issue. Then I tried a lower poly version of my robot, and > I got to an acceptable performance (<25ms to render a frame) at less than > 50k polys, which is very low. > Gazebo (with ogre as rendering engine) can handle the big mesh without too > much trouble. > I will attach a modified version of the assets demo source that reproduces > this issue. > I am using nvidia driver 510.85.02, Optix 7.2.0 and Chrono > commit 8626c8bb65fceb59129a003ed916377065cd3a1b (the last one that was > compatible with Optix 7.2.0). > Kind regards, > Patrick > > On Wednesday, 7 December 2022 at 23:09:13 UTC-8 Patrick Op wrote: > >> Hi, >> I am evaluating the viability of project chrono for a robotics simulation >> application. As part of this, I need to import a large mesh (~1.3 million >> faces) into my simulation. The whole thing uses the same, single color >> visual material. >> >> auto body= std::make_shared<ChBodyEasyMesh>( >> filename, >> 7000, >> true, >> true, >> false, >> std::make_shared<ChMaterialSurfaceSMC>()); >> >> This works fine. However, it really slows down my camera sensor. I have a >> single camera sensor (ChCameraSensor) facing the mesh. >> >> auto cam = chrono_types::make_shared<ChCameraSensor>(floorBody, >> 40, >> pose, >> width, >> height, >> 1.4, >> 1, >> >> CameraLensModelType::PINHOLE, >> false); >> >> Rendering a frame (specifically, the ChSensorManager::Update() call) >> takes over 100ms, where it only takes a few milliseconds if I have some >> simple cubes in the frame. >> I have tried the following things to speed it up: >> 1. Reduce camera resolution by 10x, this had no effect! >> 2. Add more cameras to see if it scales at all, this had no effect! >> 3. Increased MaxEngines on the SensorManager, no effect >> 4. Set RayRecursions on the SensorManager to 0, no effect >> 5. Adding no extra filters to the camera, no effect >> 6. Use ChVisualSystemIrrlicht to visualize, this performed even worse >> 7. Run on a powerful desktop with a high end GPU, this performed slightly >> better, but not by much >> 8. nvidia-smi shows that the GPU is not being utilized anywhere near 100% >> >> I am really surprised by this, as the settings on the cameras do not seem >> to influence this at all. Is there something I can do about this, or can >> Chrono Sensors just not handle large meshes like that? >> What is it the sensor manager doing with all this time? >> >> Kind regards, >> Patrick >> >> -- You received this message because you are subscribed to the Google Groups "ProjectChrono" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/d0644a09-b1fa-4689-ae88-1215212b142cn%40googlegroups.com.
