Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Suggestion / Idea  Option to limit the number of particles in a given actor
#1
A feature I have implemented myself is the ability to define a maximum number of particles a rope can possess when it generates.

One thing I noticed during testing is it is easy for the player to accidentally select two very distant points when deciding to join them together with a rope. For example, point A is at your feet, and point B is on the side of a distant mountain. Even with a modest resolution of 0.1, it'll quickly bring the game to its knees as expected.

Now that surface-based collisions are a thing, it seems especially appropriate to allow hard limits on the number of particles when they are converted. For premade blueprints, it'd make sense to not include this feature since you can determine ahead of time how many particles will get generated. Though for player-made ropes it can get flaky.

I figured since you liked at least one idea I had, I thought I'd share this one. It's at least the least controversial idea I have currently.  Guiño

(This could also apply to other types of actors.)
Reply
#2
(20-05-2021, 09:16 PM)Hatchling Wrote: A feature I have implemented myself is the ability to define a maximum number of particles a rope can possess when it generates.

One thing I noticed during testing is it is easy for the player to accidentally select two very distant points when deciding to join them together with a rope. For example, point A is at your feet, and point B is on the side of a distant mountain. Even with a modest resolution of 0.1, it'll quickly bring the game to its knees as expected.

Now that surface-based collisions are a thing, it seems especially appropriate to allow hard limits on the number of particles when they are converted. For premade blueprints, it'd make sense to not include this feature since you can determine ahead of time how many particles will get generated. Though for player-made ropes it can get flaky.

So you're clicking on two points in screen space, then creating a straight rope between their world-space projections. If you hit some object in the foreground and a very distant mountain by accident, you can end up with a kilometers-long rope. Right?

In this case I think it is justified to perform a distance check prior to generating the rope. Then adjust the rope resolution, or warn the user that he's about to create a really long rope and either disallow it or bring the distant point closer to the camera's near plane. You could also just limit the raycasting distance to a reasonable value.

It's a quite specific use case, I'm not convinced it merits an internal check. It also can't be applied to cloth (exactly one particle per mesh vertex), fluid (you explicitly set the amount of particles) or softbodies (at most one particle per mesh vertex). Moreover, some people use Obi for offline stuff (cinematics, exporting Alembic data, etc) so limiting the amount of particles would get in their way.

(20-05-2021, 09:16 PM)Hatchling Wrote: I figured since you liked at least one idea I had, I thought I'd share this one. It's at least the least controversial idea I have currently.  Guiño
Controversial ideas are what push the world forward, so keep 'em coming Sonrisa. I have zero resistance to change, as long as it seems to be for the better.
Reply
#3
(21-05-2021, 08:44 AM)josemendez Wrote: In this case I think it is justified to perform a distance check prior to generating the rope. Then adjust the rope resolution, or warn the user that he's about to create a really long rope and either disallow it or bring the distant point closer to the camera's near plane. You could also just limit the raycasting distance to a reasonable value.

I guess. But when given the choice between limiting the player, or allowing the player to do more but shaping the tech to hold up to the player's abuse, I'd take the latter route if it is technically feasible. Which it is in this case.

That being said, it was easy enough to implement on my own, so no sweat. Good thing we get source code access! (Unlike a certain other software suite...)
Reply