WorldView display rewrite

[robn]

Just some notes about how I expect it to hang together.

The UI has a concept of layers, which are full-screen (or full context-area, but thats a technicality) overlaid widgets. All input goes to the top layer only, but the back layers all receive update and draw calls every frame. Its only used very sparingly right now, for the bulletin board forms. They look like a dialog box, but they're actually a 3x3 grid container with content in the centre cell placed on top of a semi-transparent black background to produced the "greyed out" effect.

I'm intending to layer the entire display as follows, from back to front:

• World (ie raw camera)
• World effects (speed lines)
• Cockpit (including instruments)
• HUD #1 (projected elements eg targets)
• HUD #2 (flat elements eg scanner, contact list)
• Menus, station screens, etc

So each of these is a separate UI widget. Some will be containers (eg HUD #2), others not. Some are going to need to do a hell of a lot of work, others not. But that seems like a good starting point for keeping things fairly well contained.

There will need to be some shared state between them, most notably camera orientation & position for drawing the 3D elements and the camera frustum for projections. I think these can be held in a separate shared structure calculated right at the start.

Keeping them separate makes it really easy to produce different effects too. We can destroy the HUD independently. We can just use the camera widget to implement missile cams, ground surveillance, drones, whatever - these are all standard UI widgets and so can be embedded anywhere. It also allows/forces some good code structure, like the physics and lighting stuff that the cockpit will need.

There's a change required for input here - it needs to be possible for a layer to pass an event down to a lower layer, rather than the current situation where only the top layer can ever receive events. Once we have that then any unhandled event on HUD #2 (like a background click) gets passed to HUD #1, where maybe a ship was clicked or something. Or to the cockpit instruments from there.

There's still some stuff up in the air around shortcut keys and "catch-all" event handling for flight control. jpab and I have talked about these a lot in the last year and I think we're pretty closing to knowing what we need to do. I'm not going to dwell on it further here, at least not yet - input is a fair way off in this stuff anyway.

Slight aside, possible bikeshed argument: I'm not sure if projected elements should be behind or in front of the cockpit. The argument for in front is that you want to see eg the targeted ship even if its behind the cockpit (and its probably projected onto your helmet/eyeball anyway). Against is the fact that you don't want crap obscuring your cockpit when you're trying to click something. But the beauty of this arrangement is that we'll be able to swap the order just by swapping lines of Lua around. So we'll be able to experiment.

I started some experiments today with a UI camera widget, see robn/new-ui-worldview. But I think I won't go much further until I've pulled a good amount of the state out of the core Camera class so I can build on top of it.

That's all I've got for now!

[nozmajner]

Seems reasonable, even if I don't know too much about it to provide direct assistance with it. :)
Do tell me if you need any graphics work done for ui elements or anything.

I agree with target elemeents and stuff should be over the cockpit/projected on the helmet.

[robn]

So Fluffyfreak and I are both hacking in similar spaces, with the cockpit rewrite in the middle of it.

The two big things for the cockpit code are the physics and the lighting. The "calculate light for this point" code needs to be lifted out of Camera itself. The physics (ModelBody) stuff I'm not so sure. The cockpit acts like a physical object, but it doesn't exist in the world itself. It also smells a lot like a UI widget, and will even more so in the layered approach that I outlined above. Really the most it needs to get the job does is a physics timestep call, but I haven't quite figured out what the right abstraction is.

I'm doing some preliminary work right now to break out the frame state from Camera into an separate object. The basic idea is that you create an object set up the position and orientation on it (ie what the CameraControllers do) and then create the camera frame. Then you pass this down to the Camera, the speed lines widget, the cockpit, anything that needs projection. So they all get neatly disconnected from each other without needing to create remake all that stuff every frame.

Right now (I'm only one commit and a couple of hours in) it just produces a Frame* for the camera frame, just like the old code. Really the only thing this gets used for is to get the transform to get objects into camera space, so it can probably be replaced fairly easily. I just need to think a couple more bits through, not least of which is the current physics interpolated transform for the frame. Yay, more physics.

This is on robn/camera-refactor right now.

So yeah, keep talking about the rewrite you're doing because we're both thinking along the same lines. Hopefully we don't get in each others' way too much :)

[FluffyFreak]

I'll try to post some more tomorrow, gotta hit the hay now :)

[FluffyFreak]

My plan to fixing this, as I mentioned in the other thread, is just to stop it being a separate model.
The cockpit class is in effect just a controller for a node in the ship model itself, one that is usually hidden unless you are using the internal view.

I haven't tried it yet but my first thought was to have a LOD(-1) to be used whenever the camera is within the ships collision sphere/box.
The ship definition would still be used to define what cockpit is attached to the model, a specific or custom one or the default, then it attaches it to the ship models scenegraph. This is sort of how the shields work and is how the gun example from the modelviewer that Luomu did works. Then there's no need to manage lighting, transforms or a bunch of other stuff it just becomes an integral part of the scenegraph model that you are rendering.

As an aside: This has a potential advantage in that it means each ship can have it's own mesh geometry showing the body of the ship if we wanted it because it's just grouped under the same LOD(-1) but I digress.

I think the separation as you've described it is still worthwhile, there's lots of crusty and interlinked things in frames/camera/views/modelbody etc so it's totally worthwhile doing but that's my plan for the cockpit itself.

[robn]

When you first said "connect the cockpit to the scenegraph" I thought you'd gone nuts. But it only took half an hour of pondering to completely agree with you (and then two days to actually get around to replying!).

Having it at the highest (closest) LOD even makes a sort of weird sense - if you were up close, that is what things would look like. I would probably enable it based on some flag because just having the camera inside the collision volume isn't enough - that can happen quite easily with NPC ships. But that's a technicality really.

Allowing ships to provide a LOD(-1) means that for something like the DSMiner where the cockpit is to the rear of the ship, we could let the player see the whole top/front of the ship in detail. I think that's a really good thing to do.

The only thing that isn't directly possible this way is the head look, but really we can just say that that's an additional function of the camera (or camera controller) - just an extra orientation to apply. Its not a big deal.

Yeah, really like this. Nice :)

[FluffyFreak]

When you first said "connect the cockpit to the scenegraph" I thought you'd gone nuts.

With me this is quite probable :D

Hopefully I'll get around to doing something about this soon.