[GhylTarvoke]

I only have a smattering of FRED knowledge, so I'm not sure if this is possible. First, a description of the intended effect: within a nebula, the player explores a seemingly infinite three-dimensional "grid" of Shivan Comm Nodes, with each Node occupying a lattice point of the grid. This occurs without any detriment to frame rate.

Now, here's how it works: the nebula hides the true number of Nodes. There are only eight, which occupy the vertices of an imaginary cube surrounding the player. Every time the player passes through a face of the cube, the entire cube is reflected over that face. In other words, four of the vertices are translated beyond the player, with the result that the player is still inside the cube. The trick is that the player never sees this happening, because the edges of the cube are slightly longer than the nebula's draw distance; the four closest Nodes don't move, and the other four are too far away for the player to see them moving.

We can modify this technique to create the illusion of a (very large) bounded grid, by moving the Nodes only when the player is inside the grid. Similarly, we can modify this technique to make the grid appear hollow (perhaps with an installation in the center), or some other shape.

One issue is that damaging the Nodes would make them distinguishable. We could solve this by sheath-shielding the Nodes, for narrative reasons (the Shivans place great value on the superstructure). Another issue is that sensors would give the game away. We could solve this by disabling sensors, again for narrative reasons (nebular interference). A final issue is that moving a Node may cause it to occupy the same position as another object. If so, would one object be displaced, or would one object be trapped in the other?

Anyway, I think this would create interesting scenery, maybe even allowing a mission to take place in Shivantown - which is one of my fantasies, I admit.

[Shivan Hunter]

Depending on how much you wanted to do with it, that would range anywhere from "quite doable" to "lol nope".

As to your specific question about one object trapped inside another: it can sometimes work, but unless you disable collisions, FS will spaz out (especially with animated submodels!)

My main issue with that would be that your grid of nodes with no variation or changes in layout etc would be visually extremely unimpressive and unfitting of a Shivantown setting - how would you use it in a mission and keep it not mind-numbingly boring? Not trying to be overly harsh here, but "an infinite grid of the same model over and over" would not exactly be an iconic setpiece. A better Shivantown setting would involve megastructures of some kind, and anything big enough to be really impressive (Dyson spheres, black hole supercomputers, planet-sized battleships, [REDACTED]) would have to be a skybox anyway.

[GhylTarvoke]

Darn it! There wouldn't be a way to force the objects apart?

Good point. I was thinking of the Dyson sphere exterior in Freelancer, or the Monolith in Space Odyssey: visually repetitive, but colossal and abstract.

[Shivan Hunter]

If you wanted them the same, you could just procedurally create and vanish them them over and over unless that doesn't work. No moving involved, so no collision derpiness.

But anyway, this setting wouldn't evoke a sense of being "colossal and abstract", since the player wouldn't be able to see much of anything - it would just be the regular soupy nebula with some comm nodes interspersed. There might be ways to make it seem ominous as a kind of BP-style Nagari dream, but as an actual, physical structure this kind of array just wouldn't be interesting. :/

[GhylTarvoke]

So creating nodes wouldn't cause the same problems as shifting them? For example, if the node's new position were occupied by a hapless fighter.

Now that I think about it, you're right - with only a few visible nodes, it would be unimpressive. Maybe the cube could be enlarged to a 4x4x4, but that's already a lot to handle.

[Shivan Hunter]

hmm, I'm dumb. Yes, collision would still be a problem. You might be able to keep ships away from the lattice points somehow though (of course larger ships could just be flown using waypoints, not sure about solutions for fighters).

With only a few visible nodes, it would look mysterious but not much else (possibly, with some randomness and revision, suitable for a Nagari dream like I mentioned). With more nodes, it would look boring. There's really not much you could do about that, I don't think.

[GhylTarvoke]

Again, good points. Ah well. Thanks for satisfying my curiosity!

[Goober5000]

Well, hang on.  To my knowledge, this sort of mission has never been done before.  Why not try making it and see if the experience bears out the predictions?

[GhylTarvoke]

Hmm... I still can't figure out the "two objects might occupy the same position" issue.

I could spawn the node far above its target location (to minimize the probability of conflict), then slide it down really fast. But that might catapult a hapless fighter, which is just as bad.

How is it handled in the case of subspace jumps? Maybe I could follow that example, or make the node jump in silently and invisibly.

[zookeeper]

Collisions shouldn't be a problem as long as you keep all the nodes as part of the same collision group.

As for your plan in general, you should indeed be able to do it as one ship which just switches position as the player moves around, but only if the nodes can't take damage, have damage spews or be targetable, because obviously things like that would glitch out when the position shift happens.

Note that you don't need to limit the lattice size and nebula distance so that only one node can be seen at a time. If you wanted to go overkill, you could make the cube 1000m across and have nodes every 100m (so 1000 nodes total), and move the cube in 100m increments, not 1000m increments. It would probably work better visually if you could see slightly more than 1 node at a time.

[GhylTarvoke]

It's not collisions between nodes that I'm worried about, but collisions of nodes with other objects. Say I move a node to position (x,y,z), but just by chance, a fighter is near that position. If I disable collisions between them, the player may get close enough to see them passing through each other.

My plan was to have eight nodes in total, so you'd see more than one at a time. I'm worried that enlarging the cube (even to 4x4x4) would cause slowdowns.

[zookeeper]

It's not collisions between nodes that I'm worried about, but collisions of nodes with other objects. Say I move a node to position (x,y,z), but just by chance, a fighter is near that position. If I disable collisions between them, the player may get close enough to see them passing through each other.

Right. Assuming the grid is sparse, the chances of that would be low, but of course it'd be possible. However, I'm very doubtful that the AI is very good at avoiding even the current locations of the nodes anyway because it is flying inside another ship and avoidance checks are pretty much about avoiding crossing into another ship's bounding box or radius, so that might not be your biggest problem in the first place. If you make them collideable against each other, the AI might just end up in perpetual avoidance mode trying to get out without actually avoiding the nodes.

Anyway, it'd be entirely possible to script something which would automatically teleport ships out of the way of the moving nodes.

In terms of collisions and AI behavior, it might be best to just make each node a separate ship, and dynamically keep updating their positions around the players. Since you don't need a huge amount of them visible at any given time, it probably wouldn't drain much performance, especially when presumably there's not tons of battling capships and other action going on at the same time.

My plan was to have eight nodes in total, so you'd see more than one at a time.

Assuming I've understood your intent correctly, that wouldn't work. If you're very close to a node, facing out of the box, you should be able to see the next node in the distance... but you can't, because the box hasn't shifted yet, and the distant node will pop up only when you fly out of the box. To have it work with a box of eight nodes, you either can't see more than one node at a time, or you get aforementioned pop-up, or you need several boxes.

I'm worried that enlarging the cube (even to 4x4x4) would cause slowdowns.

As for performance, I think it really depends on how complex the meshes are. I don't know what size they're supposed to be, but I can't imagine much reasons to make them so complex that having 20 nodes in view at the same time would cause a problem.

The bigger impact would probably come from collision detection, because ships would continuously be inside the cubes, causing submodel and/or poly-level collision checks every frame. However, that's also probably not an issue because as far as I can tell, the BSP tree -based poly checks should deal with a mesh like that very efficiently.

Since you haven't said which way you're intending on doing it: whether splitting each node off into its own submodel or keeping the whole box as one is better in terms of performance is something you'd probably have to test.

[AdmiralRalwood]

He was talking about a cube made out of Shivan Comm Nodes, not some special-purpose model.

[Mito [PL]]

You could make the grid itself by placing a LOT of a low-poly objects (like SJD Sathanas?) and just changing their model to Shivan Comm Node when the player is close enough. Of course, including changing their class back when the player is too far. That would give you a grid, but it would have a limited size. There wouldn't be any problem with placing bigger objects like installations inside it, though. The same goes for fighter wings and warships.
And if the player would leave the huge cube made from SJD Saths and other stuff, you could just teleport him to the opposite side of the cube. That would also make the illusion of neverending grid of Shivan Comm Nodes. And some other objects in it...

But the question is: how big the grid could be with FSO's subsystem per mission limits?

[zookeeper]

Here's an unpolished prototype of a scripted solution, stuff in a -sct.tbm:

Code: [Select]

#Conditional Hooks

$Application: FS2_Open

$On Mission Start: [

    node_dist = 3000

    -- Use uneven values here;
    -- Value 2 makes the lattice 5x5x5; 3 would make it 7x7x7, 1 would make it 3x3x3
    grid_w = 2
    grid_h = 2
    grid_d = 2

    nodes = {}

    for x=-grid_w,grid_w do
        nodes[x] = {}

        for y=-grid_h,grid_h do
            nodes[x][y] = {}

            for z=-grid_d,grid_d do
                local newpos = ba.createVector(x * node_dist, y * node_dist, z * node_dist)

                local newnode = mn.createShip("Node " .. tostring(i), tb.ShipClasses["Shivan Comm Node"], nil, newpos)
                newnode.CollisionGroups = 64

                nodes[x][y][z] = newnode
            end
        end
    end

]

$State: GS_STATE_GAME_PLAY

$On Frame: [

    local pos = gr.getCurrentCamera(true).Position

    local xo = math.floor(pos["x"] / node_dist) * node_dist
    local yo = math.floor(pos["y"] / node_dist) * node_dist
    local zo = math.floor(pos["z"] / node_dist) * node_dist

    for x=-grid_w,grid_w do
        for y=-grid_h,grid_h do
            for z=-grid_d,grid_d do
                local newpos = ba.createVector(xo + x * node_dist, yo + y * node_dist, zo + z * node_dist)
                nodes[x][y][z].Position = newpos
            end
        end
    end

]

#End


[GhylTarvoke]

In terms of collisions and AI behavior, it might be best to just make each node a separate ship, and dynamically keep updating their positions around the players.

He was talking about a cube made out of Shivan Comm Nodes, not some special-purpose model.

Right, this is what I meant. It would be a FRED sleight-of-hand, not a modeling one.

Anyway, it'd be entirely possible to script something which would automatically teleport ships out of the way of the moving nodes.

I like this. It might cause a domino effect, though - where would I teleport the ship? The target location could be occupied.

If you're very close to a node, facing out of the box, you should be able to see the next node in the distance... but you can't, because the box hasn't shifted yet, and the distant node will pop up only when you fly out of the box. To have it work with a box of eight nodes, you either can't see more than one node at a time, or you get aforementioned pop-up, or you need several boxes.

The trick is that the player never sees this happening, because the edges of the cube are slightly longer than the nebula's draw distance; the four closest Nodes don't move, and the other four are too far away for the player to see them moving.

-----

As for performance, I think it really depends on how complex the meshes are. I don't know what size they're supposed to be, but I can't imagine much reasons to make them so complex that having 20 nodes in view at the same time would cause a problem.

Even if only a small fraction were visible at any time, wouldn't the mere existence of (say) 64 nodes impact performance? If not, that would make me very happy.

You could make the grid itself by placing a LOT of a low-poly objects (like SJD Sathanas?) and just changing their model to Shivan Comm Node when the player is close enough. Of course, including changing their class back when the player is too far. That would give you a grid, but it would have a limited size. There wouldn't be any problem with placing bigger objects like installations inside it, though. The same goes for fighter wings and warships.
And if the player would leave the huge cube made from SJD Saths and other stuff, you could just teleport him to the opposite side of the cube. That would also make the illusion of neverending grid of Shivan Comm Nodes. And some other objects in it...

But the question is: how big the grid could be with FSO's subsystem per mission limits?

The SJD thing wouldn't be necessary in a nebula with no sensors. An installation within the superstructure would be cool - like a nexus of the network. I don't think teleporting the player would work, unless you also teleported every (non-node) object around him.
-----
Wow zookeeper, you wrote a prototype? That's awesome. It looks surprisingly simple and elegant.

[zookeeper]

So... did it work?

[GhylTarvoke]

Been slammed at work, but I'll test it over Thanksgiving.