v3.x.x

[sasha240100]

Great to announce that start of v3.x.x development!

Short FAQ:

• When? Probably till the end of this (2018) year
• Who? @sasha240100 @hirako2000 and everyone who wants to join (you can ask in this issue comments & propose your changes)
• What it will be? Yep, the most interesting question, I'll write down below.

Proposed features

• New Three.js version in the core of the library + Support for further version updates
• Components automation. Three.js always adds new types of geometries, lights, meshes and so on and currently we handle them manually. We would probably write a code that will parse three.js geometries/lights/etc and make components from them.
• Better WHS.Loop I really like that we split requestAnimationFrame into loops, but I think we can do that an even better way [API is currently under discussion].
• New (simplified) Module lifecycle. Same. Modules is a strong part of whs framework, but their complexity is whs weakness, and we'll try to make them more human-readable and better-piped way.
• Support for new Three.js features.
  • THREE.WebGL2Renderer support
  • (soon...)
• Better documentation. (more details soon...)

Feel free to add your suggestions to the future release in this issue comments

Subtasks:

• Setup @whs/w-examples #397 Setup @whs/w-examples

Version:

• v3.x.x
• v2.x.x
• v1.x.x

Issue type:

• Bug
• Proposal/Enhancement
• Question
• Discussion

---

Tested on:

Desktop

• Chrome
• Chrome Canary
• Chrome dev-channel
• Firefox
• Opera
• Microsoft IE
• Microsoft Edge

Android

• Chrome
• Firefox
• Opera

IOS

• Chrome
• Firefox
• Opera

[noahcoetsee]

Of course, I'd like to help out! My workload will decrease in school from January until May, so I have time to contribute towards the development/expansion of base features. Should I continue developing my Networking Module? Are we going to throw that one out during 3.x.x?

I love that we're getting active in this again. This library has much more potential than the number of people that (properly) utilize it in the actual world...

Here's to high hopes! 😄

[bbzz7]

Very excited, I am looking forward to its release~！

[bbzz7]

I think it is possible to add a more convenient loop/tick management module so that the loop/tick can be handed over to other libraries, such as an animation engine such as GSAP or other

[sasha240100]

I’ll start at 19 Jan

…

On Sat, Jan 12, 2019 at 4:11 PM ZhuangYu ***@***.***> wrote: I think it is possible to add a more convenient loop/tick management module so that the loop/tick can be handed over to other libraries, such as an animation engine such as GSAP or other — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#395 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHTX1Zuxts0aDjpvAbTzuIQ-0amAxrejks5vCe0MgaJpZM4ZE7BC> .

[noahcoetsee]

Roger that.

[hirako2000]

I think v3 can/should provide improvements suggested by the community, but bring something entirely new to the creation of 3d scene/games to the user.

My proposal to Alex is to bring the world of 3d webgl rendering (with three.js/whs) to the so polular Scratch platform.

With the release of scratch 3.0 it is still impossible to create 3d environments using visual block programming. All it supports is low level ray tracing logic that would never perform for real time interaction that includes modern visual elements.

WHS has the foundation to help beginners create their own scenes with basic/little JavaScript knowledge, it would take whs to another level if creators who only grasp the visual block programing concept could also create webgl enabled projects.

If you support the idea, please thumb up (or down if you dislike)

[noahcoetsee]

I, unfortunately, must disagree with you, @hirako2000 , for a couple of reasons:

---

1. WHS's goal for this project seems to be streamlined integration of physics into WebGL, and I think that's a great focus. Not that integrating into Scratch would be bad, but I think it'd be a sidetracking goal from what the real premise of the project is.
2. WHS's structure is highly Object Oriented, and Scratch is extremely pragmatic and forward facing.
3. There are many other community requested features and bugs and such to be fixed, and I think we should focus on interaction within normal Javascript code, not through any sort of port to another scripting language.

4. WHS has the foundation to help beginners create their own scenes with basic/little JavaScript knowledge, it would take whs to another level if creators who only grasp the visual block programing concept could also create webgl enabled projects.

While this is true, WHS was also built to help people learn to actually code, not to drag blocks, as much as that would help bring people towards the journey, it wouldn't really help people learn Javascript in a more simplified manner.

Overall, I think this would be a great idea for a port of this, or another certain project. But this just doesn't seem like the right extension of the feature-set for this project. Doesn't seem like the right direction.

Everything stated here was just my opinion and is open to discussion and/or debunking (I didn't really fact-check except for with the goals of WHS).

I hope I don't come off as harsh or ignorant.

• Noah

[hirako2000]

Thanks for your input @noha, good points. A bridge for block based programming usingwhs as an engine would just be a different project then, I will look into it outside the v3 scope.

[noahcoetsee]

That sounds good. I appreciate you listening to my concerns, and I'd love to help you with such a port to Scratch in some time.