Treejs LoadScreen and Trnsitions

[TNick]

This is just an idea and comments are welcomed.

I merged the two helper functions in playground.three.js but I'm not particularly proud of that. Maybe the place for this files is in plugins/threejs, with

• three-helpers.js having those two functions (rename playground.three.js),
• playground.three.js contains the render (rename playground.threestarter.js)
• other files

Also, the css solution for transitions is flexible but has the nasty effect that css must be embedded in the js, otherwise the user must remember to include the css files, those files must be part of the distribution, etc. Any thoughts on that?

[rezoner]

@TNick

Hiya, thanks for the contributions!

I am not very fancy adapting CSS transitions into a mainstream three.js distribution

1. CocoonJS does not support CSS
2. Shaders and direct graphics manipulations are more powerful than CSS

Nonetheless I don't have time to develop proper Three.js support now

My advice would be to put your vision of THREE support as a plugin that replaces Transitions, Renderer, LoadingScreen and etc that you find convenient.

I wouldn't be worried about putting css in separate files - the same concerns shaders anyway.

I would add transitions/ folder and implement app.loadTransitions("something") function that works in the same way as app.loadData

Also put one default css transition embeded straight into your plugin so something works even if you don't include any css files.

[TNick]

css I see your points about css transitions. Once I get the hang of three.js I will replace them.

folder Ok, so a folder under plugins would do, then.

transitions But the transitions are gonna be specific to the render that is used (at least in this case). You mean to say that the render that is loaded augments the app object with a loadTransitions? Or the application implements loadTransitions and deposits them in app.transitions to be later used by the render? And I would allow each state to specify the transition to be used when entering that state with an option - say transition.

others Also, I would move the canvas render to a plugin folder of its own for symmetry.

[rezoner]

@TNick

others

I agree that CanvasQuery based renderer should be moved out of the main tree. For readability I think we could go with renderers/canvas/ or plugins/renderers/canvas/ folder

transitions

var app = playground({

  create: function() {

    this.loadTransitions("slideDown", "fadeIn");

  }

});

app.loadTransitions would basically insert style loaded by XMLHttpRequest into DOM structure - however I still don't think it is a good idea to use CSS when u have WebGL at disposal - it's more up to you - and what your project needs tho.

css

Once I get the hang of three.js I will replace them.

I advise you to not create public code/libraries that are not outcome of real products. Write a little game (or a couple) - experience what works and then grant it to the public domain.

On the sidenote for THREE.js support - you see I am really struggling there - because I am not very experienced with it and I don't really know what's the standard for a professional game - do you want to have a camera object out of box, or multiple cameras and one renderer? That's why I've added the basic loaders and abandoned it.