Collaborating the development of a Three.js extension

[Brackets-Coder]

See #2356.

This is the discussion for the collaborative development of a Three.js extension. It includes myself, @Brackets-Coder, @Civ3ro, and potentially @Drago-Cuven if he agrees as well. I think I heard @CST1229 was also making a similar extension.

Let's face it. All the developers want to make a Three.js extension; many of them have already started. The goal is to determine whether one is actually necessary and how to make the best extension possible.

I have concerns for the fact that a 3D rendering extension already exists on the gallery and the publication of a Three.js extension might potentially make Simple3D obsolete, though things like it's manual control over transformations and smaller block pallet than a three.js extension might be appealing to some users.

I also have concerns for the ease of development when collaboration comes into play—things can quickly get chaotic.

Here's my idea:
All participants, including myself, discuss a course of action for the merging of each participant's extension into one cohesive project. This may include the discarding of code or ideas upon which we agree are not optimal, most beneficial, up to date, etc. (don't get your feelings hurt, we all have the same goal).
When we've decided the best possible merging of the extension, one participant is nominated as the "project leader" and will host a parent repository for the development of said extension, and each participant will fork the parent repo. Development will occur on a separate branch of the repository rather than the master branch.

• Collaboration and planning starts immediately upon participants joining
• GitHub will be used for all communication and version control going forward
• Each participant will recognize the schedule limitations of each other participant and be flexible with times of collaboration
• Upon the creation of the parent/master repository, this discussion will be moved to that repository

One of the first steps of the collaboration will be the familiarization with each other's workflows and codebases; after all, I don't understand what you wrote and you don't understand what I wrote. When this is complete we can decide how to best merge the various versions of the extensions—or, if no merging seems suitable due, we can just re-write the extension from Scratch (it might even be less work than getting two codebases to work together, and that way we'll all be on the same page). Throughout the collaborative process, each participant agrees to provide constructive criticism and valuable feedback peaceably to ensure the highest code quality and consistency between the varying code of the different participants.

I generally prefer working alone because it's easier to keep my thoughts centralized, but I think this will be a great learning experience for everyone. Good luck!

[CST1229]

i personally don't care much about this (CST 3D development is basically dead), but do feel free to use ideas/code from CST 3D if you need to

[Civ3ro]

I would love to participate in this!
To get some experience working in teams.

I think that my implementation is the one that covers more content, having Physics, GLB importing, text geometry... check here

(It is easy to break, get errors...
Some users experiment stretching or no compatibility to render)

But I do not have that much of experience with JavaScript coding, this was my first project!

Happy to learn 🧠

Check a small demo here

[Brackets-Coder]

Experience in JS will be very helpful
Whether #1974 gets merged likely determines whether we include physics or not; if it does we can include some kind of API passthrough like Simple3D that enables the two extensions to talk to each other. This way we won't have to include physics in the extension

I'm busy at the moment but I'd love to take a more in-depth look at what you've written and see what we can do with it.

[Brackets-Coder]

To be honest, everyone is going to want their version to be the one that stays so the critical part is deciding what stays and what goes. Also, we could just write from scratch (no pun intended).

[CubesterYT]

Hello! I just want to interject because I think this is a cool idea, but I also have a side quest like proposition for you guys

As everyone here knows, I own a TurboWarp mod called NitroBolt, and we have a native 3D extension planned.

What I propose is that you can also join us to work on it eventually! We already have one person on board, but the more the merrier!

NitroBolt's implementation would definitely surpass anything you can do with an extension only.

[Civ3ro]

Yeahhh nitrobolt!
I'm on!

[Brackets-Coder]

I'd only agree to NitroBolt if it would be the same extension developed for Turbowarp and if Turbowarp had the same 3D extension as NitroBolt; only not natively included in the pallets. I wouldn't want to make two different extensions. What you're describing sounds like something integrated into the VM and GUI?

[CubesterYT]

I think the major differences would be that NB's would be within NB like the pen extension is, and we'll be using special made apis, hooks, features, etc.

Trying to make it fully fleshed out.

It wouldn't hurt to try something beyond and more capable l

[Brackets-Coder]

Of course, I was only supposing that instead of writing something new we could build off of an already existing Three.js extension

[Brackets-Coder]

Here are the links to some of the code:
https://github.com/Civ3ro/extensions
https://github.com/Brackets-Coder/ThreeJS-Extension - this one is barebones and just a demo
https://github.com/CST1229/turbowarp-extensions/tree/3d