Using SPS versus ThinInstances for rendering procedural asteroids

Questions
1

I’ve got a orbital simulation of a solar system that includes a procedurally generated asteroid belt. Currently, the rocks are proc’d using an SPS, and it seems to work just fine.

After doing some reading and watching @PirateJC videos on ThinInstances though, I’m wondering if it might be a better solution to use them instead of the SPS.

Advantages:

  • Individual control over each asteroid, which would give the scene a more dynamic and evolving feel
  • ability to perform collision detection between individual asteroids and the player
  • performance improvements?

Disadvantages

  • current setup works fine, changing over is time/effort that could be used elsewhere
  • game design doesn’t require fine grained collision detection in this context
  • raises potential for defects and related resolution efforts

Does anyone have any sort of guidance they like to follow when making these types of decision? Given the above context, does it make sense to be considering this right now when there are a lot of other things that need implementing, or will it be relatively easy to do this at some time in the future?

Thanks for any insights!

2 Likes
2

I think the SPS is fine if the rocks are static, you will get the same kind of perf as both are drawn with a single draw call.

With thin instances, you would get:

  • better perf if moving/rotating the rocks individually, as it’s only a matrix change for thin instances whereas the vertices/normals of the rock have to be updated in the SPS case
  • less GPU memory usage, as you only use vertex/index memory for a single instance of the rock and then consume 64 bytes (a 4x4 matrix) per instance. In the SPS case, the vertex/index memory consumed by a rock is multiplied by the number of particles

Regarding intersections, it will be faster with thin instances but intersections are done at the instance level, not at the face level (contrary to SPS).

One caveat is that you won’t be able to modify the vertices of the rock at the instance level if using thin instances, as you do with SPS. That’s something you may be able to do by changing the vertex shader, tough.

As an example with all rocks updated each frame (rotation update):
SPS:
https://playground.babylonjs.com/#5BS9JG#57
=> 15 fps

Thin instances:
https://playground.babylonjs.com/#5BS9JG#59
=> 60 fps (absolute fps: 300-330)

4 Likes
3

Thanks for the PG @Evgeni_Popov - I gotta say, seeing the way it looks with the lighting and each rock tumble individually, it looks amazingly better!

What you said about deforming each instance and such in a vertex shader - were you referring to run-time deformation or the general procedural generation needing to be done in the shader?

4

What I had in mind is updating the vertex position in the vertex shader based on a noise texture, and using a seed position in that texture based on the instance so that the deformation is different for each rock. So, basically you would pass a noise texture to the shader and add an attribute to the thin instances to pass this seed to the shader. In the shader, you would lookup the texture based on the seed to perturb the vertex position. You could also use some shader code instead of the texture to compute the noise.

1 Like
5

Ty, you took the much more vague thoughts I was already thinking and put them down much more clearly!

I’m thinking I might want to refactor to use this approach as it doesn’t seem like it adds a lot of complexity that is exposed to other code in the game. Thanks for the help!

1 Like
6

Sounds like a great plan!

Super interested to see what you are putting together :slight_smile: I am a huge nerd for anything space-related. Keep us posted!!

2 Likes
7

Thanks for the interest @DarraghBurke!

At the moment, I’m working on integrating gravitational physics and the Ammo plug-in into the webpack-based web application the PG is for - this is the current staging site

Ed: controls- use a,d to swivel, ctrl/shift to adjust force, spacebar/enter to launch, and delete or backspace to reset the simulation

I’ll definitely be posting more about this project here in the coming future, but in the meantime, feel free to check out the project’s repos and discussion on GH!

1 Like
8

I love it!! Starred :smiley:

I especially like the “Powered by Babylon.js” splash screen :wink:

2 Likes
9

I’ve updated the repos and staging link (above) with the Thin Instance asteroid implementation provided so kindly by @Evgeni_Popov (:pray:!). It ended up being really easy to adapt the PG sample to the code base, and it looks really good.

I can even see how it would be pretty straight-forward to get each asteroid to follow its own independently calculated orbit if I needed to.

2 Likes