Jerky camera movement with many objects

[hofk]

There Circular control used for walkable areas control I have described a procedure how to move a person in an environment.

This works very well in the very spartan test environment. One can try it out there. In the article there is also a picture of a somewhat more elaborate showroom under development. Another incomplete room (video) and its definition by construction data can currently be seen there (third section) https://hofk.de/main/threejs/

The room contains floors, ceilings, walls with openings and fillings (self defined non indexed buffer geometries) with textures, also video. Also loaded obj and gltf objects. And a few CylinderBufferGeometry and BoxBufferGeometry. Also mirrors, which work again in r116 with Scene.background. There was a bug before.

---

https://github.com/mrdoob/three.js/releases
Reflector
Fix rendering bug when using Scene.background. #18973 (@Mugen87)
Remove recursion parameter. #19078 (@Mugen87)

---

All meshes are added to the room.
room.add( …Meshes[ i ] );

For each type… there is a array that is processed for generation.

The more I equip the room, the more jerky the movement that is realized with the help of the control https://github.com/hofk/threejsResources/blob/b17b227b6dc8756871283722e833b270bafa47fe/Circular-%20Area-Control/AreaControl.js.

At a certain point, this is no longer practicable.
I do not know whether there is a practicable solution for this.

Is there any benefit in creating all non indexed BufferGeonetries as a single one when defining them?

So only one
construction.setAttribute( ‘position’, new THREE.BufferAttribute( positions, 3 ) )
instead of the many individual ones? And only one positions = new Float32Array( positionCount ); ?

This makes considerable conversion effort and is not very clear in the program code but may be feasible.

Or is the AreaControl.js approach possibly unsuitable for this application?
I do not want a camera movement on a predefined path.

I’m grateful for any hint.

[hofk]

I ran some tests, based on Circular control used for walkable areas control . For this I added a lot of meshes in an example. Much more than my room has. For this purpose I added .toNonIndexed() to the BufferGeometries as a test, because my room elements are mostly of this kind.

This test arrangement runs quite smoothly. Only when the mirror is in the field of view of the camera it gets a bit jerky. Try it there.
https://hofk.de/main/threejs/showroom/AreaControl_TEST_01.html

In my room I took out the mirror - no improvement.
The strange thing is that the jerking in different places is different. But sometimes strongly, where only two or three walls and floor, ceiling are close to the camera.

One guess is that the many commands .addGroup( …, 3, … ) “fragment” the geometry. However, this does not fit the behavior when only two or three walls of two triangles and one material each are in the camera’s field of view.

Combining the material groups for my room is very complex and only worthwhile if it is really a solution.

What is the background to the fact that the material groups are created using elaborate script objects { start: integer, count: Integer, materialIndex: Integer } and not via BufferAttributes?

Still baffled.

[Mugen87]

renderer.info.render says that you perform draw calls in the range of 100 - 500 depending on the camera position and orientation. On top of that, you render almost three million triangles in some extreme cases. It’s not surprising that the FPS drops on certain hardware under these conditions.

I’m not sure I understand your reference to BufferGeometry.groups. In general, using multiple materials results in more effective render items and thus draw calls. It can be an important performance improvement to avoid such setups if you are having performance problems.

[hofk]

Thanks for pointing that out.

Tested:

In my room I have about max. 350 calls and only 200 up to 1200 triangles.

This is considerably less than in the test example AreaControl_TEST_01 with the many cylinders and boxes.

I have to keep checking.