Add 3D objects to terminal glasses

[zeroeightysix]

This PR aims to fully implement 3D objects to plethora's terminal glasses.
Contributors may want to reference #51 and the currently open issue #39

Task list

• Base: add support for 3D objects, rendering and seperating them from 2D objects
• Box object
• Line(s)
• Text
• (Custom) meshes
• Piramids
• Dot
• Ability to texture faces
• A better rendering system (modern openGL)
• Sort by distance when rendering objects so objects without depth testing don't look too odd

[redfast00]

@zeroeightysix how will this work exactly? Is there a coordinate system centered around the player, so that there can be a "virtual reality"? If this already (partially) works, can you maybe make a small video to showcase it?

[zeroeightysix]

@redfast00 Methods are (currently) just all added onto the canvas object. (e.g. .canvas().addBox(...).
The coordinates passed will be relative to the current position of the player with the glasses mounted, and the 3D object will stay there. So, for example, if you were to create a box at position 0,0,0 you'll have a box 'spawn' at your feet, and it'll stay in that location. If you move, it won't move with you.

[redfast00]

@zeroeightysix yes! That's exactly what I need, thanks. Are the virtual blocks visible through real blocks?

[zeroeightysix]

@redfast00 That you can choose yourself. Take a look at Box.java, most notably the depth testing field. It's defined when you create the box.

[redfast00]

Ah, just saw it. This is really cool, is there anything blocking merging?

[SquidDev]

Ah, just saw it. This is really cool, is there anything blocking merging?

This is still very much in a "discuss the implementation" phase. One of the things which stopped my initial implementation of this, and I'm still not sure about is how you handle the player moving. You probably don't want objects to move with you, but then how do .getPosition/.setPosition behave?

I'd really appreciate some other opinions on this, as I've enumerated several possibilities and none of them seem especially enticing. The obvious bodge would be to limit this to static blocks (i.e. the manipulator), but that's not exactly ideal.

I'd also like to see some support for 2D objects, suck as text, though that's less of priority.

[redfast00]

Here's what I think might work, please point out inconsistencies: there could be a placeHere method, that centers the 3D grid to where the player currently is (a bit like the other plethora peripherals). A player can walk freely inside the centered grid, but if they leave the cube originally centered where the player was, all rendered 3D things get dropped, and (maybe) an event fires. Where would this go wrong?

[SquidDev]

Hrmrm, I do actually like the idea of creating a new canvas each time with its own coordinate system. I'd need to do some work on child groups (like #39 mentions) before having a crack at this, but it's definitely the best solution I've seen so far.

[dmarcuse]

I really like @redfast00's idea of being able to draw things tied to world coordinates, but it feels a little bit black-box-y, if that makes sense. On the other hand, it would make the usage much smoother by not having to constantly redraw as the user moves around. I don't think it should disappear or fire an event if the user leaves the area, however.

[redfast00]

@apemanzilla I considered non-disappearing boxes, but I think users would put way too much boxes everywhere and not remove them (because they aren't in the area anymore). A potential solution would be to either limit the amount of boxes to a fixed number, or to make keeping boxes alive also have a cost in the built-in system. Let me know if you have any more ideas, the more, the better.

[zeroeightysix]

@redfast00 What's the issue with having "too many boxes"? Only the user themselves gets to see them, so it'll only bother them aswell. Or are you trying to say it's too powerful and needs balancing?

[redfast00]

It does seem a bit too powerful, and it would seem that it would hurt performance, but I haven't tested it.

[SquidDev]

Honestly, if there's any limits, it should be generalised over the entire glasses rather than just 3D objects. The better solution is probably to limit network traffic (so the number of changes in a tick) rather than some hard limit.