Add a sandbox for PortalLink and Field

[evshiron]

I found some related classes in /src/geometry/ and /src/mesh/, but had no idea how to add them to the scene and get them rendered. I am looking into ResonatorLink, thinking about there should be something common between them, and your demo in this will be appreciated.

Thank you.

[DeviateFish]

You bring up something I've been meaning to clean up for a while... Everything in /src/geometry/ is actually from the old, deprecated THREE.js-dependent version. I've yet to finish porting everything over to the new version, so I left that code in place until I got around to it. Fields, and the beginnings of particle systems were things left on my todo list... I guess I should get to them.

As for portal links, they're a little tricky, since they're dynamic meshes. Check out this little script:

https://gist.github.com/DeviateFish/f9c3a5b89eae51a9d4a8

Basically, you need to create and manage the mesh (which handles adding/removing links), then create a LinkDrawable with the proper texture for rendering. Link meshes also have a limit to how many links they can render, which currently isn't enforced... so be careful not to try to add too many links to a mesh.

I need to figure out a better way of handling dynamic meshes in general, so if you have any ideas, let me know.

[evshiron]

Looks like the Field is quite similar to PortalLink, I will attempt to adapt it if possible.

I have read about the Mesh and the Drawable, the design is not bad and I currently don't have a better idea on it. But if we want refactoring, there will be a lot of work to do.

[DeviateFish]

I've actually debated the idea of making Links/Fields single-item constructs, rather than sets of links/fields like they are (or would be).

I think this would simplify how links and fields are created, but at the cost of making them have slightly more poor performance.

Most of how I'm doing things is reverse engineered from the game client itself; but the game client has had significant performance optimizations, so some of them have made them into this library, where they seem to cause more problems than they solve.

I think resonator links might make sense to leave as a system, but fix them to a max of 8 links per system, and configure them accordingly.

In theory, this should let them be created in the same was as inventory items/portals, etc... Just instantiate a Drawable and call it a day.

Thoughts?

[evshiron]

If I were you, I will try to make code more readable and easy to use, unless the performance is really unacceptable.

The current implementation enlarges the GLBuffer when the count of links increases, and ends up throwing error when it is larger. And this can be solved by making them separate items. And within the limitation, I don't see any performance issue.

So as a conclusion, I will support making them items.

[DeviateFish]

Sorry I didn't follow up on this earlier.

I think that's a good line of reasoning. I'll make the link geometry less dynamic, make it one link per mesh, and call it a day. Should greatly simplify their use. However, it might introduce some issues with reorienting the links and such (i.e. applying transforms), so it might be worth readdressing in the future.

[evshiron]

That's a lot of work. Thanks for your hard work.

[DeviateFish]

Done in v0.17.0