fs2open.github.com icon indicating copy to clipboard operation
fs2open.github.com copied to clipboard

FR: Hardcode scalable sphere and cube for volumetric nebulae and asteroid boundaries

Open Durandal-Thoth opened this issue 1 year ago • 3 comments

Similarly to how Freelancer handles asteroids and nebulae as scalable "zones" using an invisible deformable sphere/cube mesh, this proposal would introduce a sphere and cube for freelancer which can be scaled independently on all axes and, ideally, rotated.

These new boundary meshes would be able to define the dimensions of asteroid fields and volumetric nebulae which would look like this - the white ovals in the demonstration gif here are spheres which have been scaled to accomodate debris, asteroids, and nebulae throughout a game area.

https://i.postimg.cc/NFWj7cNX/flms.gif

Durandal-Thoth avatar Jul 04 '24 20:07 Durandal-Thoth

At least for the volumetrics part: Would you expect parts in your sphere to always be completely filled with nebulae, or just partly / randomly populated? Because the former would probably be much easier to accommodate by just making it a pof. Furthermore, do you want more than one sphere / cube per mission? Remember, as of now, we can only have one area of volumetrics per mission, so we'd need to render all together. This is possible, but will obviously suffer from low resolution when stretched over a large area.

BMagnu avatar Jul 04 '24 20:07 BMagnu

  • Completely filled, this is for ease of level editing - who wants to adjust the dimensions of their pof and export a new one each time they change the shape of a nebula?

  • Allowing for more than one per-mission would definitely be ideal. What's the reason they can't be rendered independently?

Durandal-Thoth avatar Jul 04 '24 20:07 Durandal-Thoth

  • Fair enough. It might be possible to do this if it's some very few hardcoded shapes, but it's certainly not something quick, especially since it also needs a fancy new editor and way of showing it in fred.
  • It's currently a very fundamental restriction, as we only do one volumetrics pass, and this volumetrics pass gets a lot of data for its one nebula. Giving it the option to do more may work with some heavy restructuring, but only to something like 4, maybe 8 (and that will come with severe perfomance costs), but certainly not more than a dozen, let alone an arbitrary number. Doing multiple volumetrics passes is also not feasible, as they aren't aware of one another. This would cause very broken rendering as soon as any two nebulae would be visible behind one another.

BMagnu avatar Jul 04 '24 20:07 BMagnu