Nice video! Well done!
Your problems with Bandicam are probably about the OpenGL rendering. I don’t know how well 3D applications are supported. Well, it must have worked or else we wouldn’t see this video 😉
There isn’t really a limit for polygons. The engine is pretty good at throwing polygons to the graphics hardware. The bigger problem is lighting and texture bandwidth i.e. the shading of the polygons. That is very dependent on the hardware used. On some hardware you can have 3 lights with shadows at 1024*1024 resolution without lag. Some hardware barely handles one light with shadows at 512*512. Here you can optimize by using smaller resolutions for example. I noticed that lights without shadows are practically free (at least on my hardware). Could be different on other hardware though.
Another factor are state changes. That means if you render one object with many different materials instead of packing everything into one image. Some people say it’s about draw-calls. That was right for Windows <= WinXP since all graphics stuff was in the kernel mode and any draw call brought a context switch. You don't have that anymore. Today it's only about state-changes. State-changes are cached and executed when a draw-call occurs. That means that a draw-call is only expensive if you did major state changes like binding another texture etc. You can optimize that by using less materials in your objects for example by using an atlas-texture. Another way of optimizing your graphics are LODs (Level of Detail). This allows you to display a different mesh for each distance of the camera to the object. You can display much lower polygon meshes without loosing visual fidelity this way since far away objects are not as visible anyways. That could be done using a C++ behavior in Neo.