[Sesquipedalian]

It occured to me just a moment ago that the problem with big asteroid fields is this:

Each pof in a mission increases the number of entries in the collision check list exponentially, so that if there are too many asteroids in a mission, the list overruns, and weapon shots stop colliding with ships.

But what if we replaced the current asteroid pofs with pofs that contained several different asteroids in one pof?  Each asteroid in the pof could be a destroyable subsystem.  As long as the pofs are large enough, with the asteroid subsystems spaced out far apart from each other, it would not be noticable that several asteroids were moving in a group.  We could suddenly have, say, five times as many asteroids and therefore much wider asteroid fields.

Might or might not work.  Any modeller want to take a few minutes to make some pofs and test it out?

[Getter Robo G]

ty you just solved why that mission I made 3 years ago with 300+ asteroids made them non solid... (goes to rethink the mission)

[Sesquipedalian]

3 years ago?  That would be before SCP, so you couldn't have made an automatic asteroid field with more than 256 asteroids.  So you must have placed them manually.  Which means that you had to use the asteroid in the ships.tbl.  That asteroid has special flags that make it not collide with anything.  Your problem actually is not the same as the one I was addressing.

[Flipside]

Groups of asteroids would be ok for static fields, where nothing is moving, but problems could arise with getting mobile asteroids working in this way.

[Getter Robo G]

yeah it was JUST before SCP (I was using DTP 3.2 until like last year)...  If you downloaded the 22mb clip I made of that mission you can see I hand placed those asteroids for a specific reason (which is painfully obvious especially if you saw that episode on tv)... I'll look at the table entry again eventually (bot in a rush)....

[Bobboau]

this idea probly won't work, but it gives me an idea for something that would... too bad I'm too busy to try implementing it...

[starfox]

Freelancer style asteroid fields, nebulas and other hazardous areas would be really cool, but ATM nigh-impossible.

[WMCoolmon]

Hmm, what about something like this..

When the camera turns its back on an asteroid, its distance is calculated relative to the camera. If it's greater than a certain distance, it's instead flagged as being a "flat" asteroid.

What this means is that the asteroid is noncollideable, and will be represented as one square polygon (or a larger triangle) that always faces the viewer. The image for this is included with the asteroid, and corresponds to a specific orientation of the asteroid.

When the camera turns back around, and gets close to the asteroid, the polygon is replaced by the full asteroid model, rotated relative to the viewer to match the texture (so the change is instantaneous)

To cut down on collision checking, each asteroid could only have collision checks and calculations performed on its radius, or its bounding sphere. (These could be specified in asteroids.tbl, and include full-polygon calculation if the asteroid is some really odd shape.)

As a result, you'd have a helluva lot less polygons on screen even with a massive number of asteroids at a great distance.

Actually, the render-to-texture code could be used to generate asteroid images on the fly to add some variety.

Actually, just allowi8ng a less-accurate physics calculation mode for asteroids would probably help a lot too, assuming asteroids are batch-rendered.

[Fineus]

Originally posted by starfox
Freelancer style asteroid fields, nebulas and other hazardous areas would be really cool, but ATM nigh-impossible.

The trouble with that is that it forces you to have a maximum depth at which you can see, beyond that the asteroids aren't apparent.

This means that a Star Wars Ep2 style asteroid fight would be nigh-on impossible as you wouldn't get the same experience. Of course as it is it's impossible to do this for the original problem of overrunning the collision entries.