What do you want in Babylon.js - http://babylonjs.uservoice.com

[Dad72]

EH ??? Babylon is written in javascript for use in 3d on browser and not for application windows with dll.
There are Babylon with SilverLight 5 If you want to, here it is for javascript. your ideas is totally off topic.
 
You've already seen dll with Javascipt? And if you read: Babylon.js It is far from the WinForms in a browser

[testure]

Not sure if these things have been mentioned or not but:

 

- Better/more complete implementation of cannon- There are a ton of features cannon has that have not been exposed in babylon.. I've had to go through my project and add support for these features to accomplish my goals- once I finish I may do a pull request, but there are still a lot of things missing.

 

- More widespread use of common functionality. For example- I can parent a mesh to another mesh. Why can't I parent a camera to a mesh, or parent a particleSystem to a camera? Why can i use mesh.setPositionWithLocalVector but matrix.setPositionWithLocalVector doesn't exist? Why can I animate some things but not others? If it moves, it should be animatable, just like a mesh.

 

- More control over what gets cleared by a scene. Right now you can specify a clear color, or tell it not to autoclear at all- but what if I just want to clear depth? Doesn't seem to be a way to do that without going into my gameloop and calling engine.clear manually every frame.

 

- More asset deployment options. Large minified json strings stored in files is fine and all.. but why not have something that's decompressed on the client and minimize download sizes? Or better yet, why not use a compressed binary format?

 

- Ability to control global time scale. right now "pausing" a game is no trivial task. You can stop rendering easy enough- but logic that relies on time keeps on ticking (example: particle systems). Which is a nice segue into...

 

- More robust particle system. What babylon has is pretty bare bones, and it's certainly better than nothing at all.. but it emits particles, and that's about it. Doing modern effects with babylon isn't really feasible as it is now, I've had to add support for essential features like color over lifetime, size over lifetime, randomized rotation angle at spawn, velocity dampening, and emitter offsets (using an object as an emitter, and then offsetting in local space from there). Again, when I'm finished with this project I'll be doing a pull request. Additional particle system features that would bring it into modern standards:

 

- Better shader support. Honestly a particle system should just take a material as a property and use it. Blending should be done by the material's shader, not by a flag. This would allow for a robust set of default particle shaders that can do things like lighting, 

 

- Animated particles/spritesheets.

 

- Particle event callbacks. IE) collisions, birth, death, etc. With a callback you could fire off a function that has gameplay implications, or just spawn another particle emitter. For example, a drop of water hitting the ground could emit several smaller particles- or a fire particle could start emitting smoke particles when it dies.

 

- Control over particle billboard direction. Sometimes you want to billboard to a camera, sometimes you want to billboard in a specific direction.

 

- Control over emission space. You're not always going to want to emit in world space.

 

- Better control over particle emission. Right now we can supply two direction vectors and a particle will spawn with a randomized vector that exists somewhere between those two. It's better than nothing- but it makes certain effects extremely hard to make. It'd be nice to be able to have a cone emitter, as an example- where you specify an angle and direction, and particles will emit in that area. Or a sphere emitter, where particles spawn inside a given radius and emit in any random direction.

 

- Deferred rendering path. Making a halfway decent looking game with four lights is certainly possible, but it makes achieving any level of modern quality difficult. With deferred rendering we could have any number of pixel lights in addition to the various buffers that make certain shaders more cost effective.

 

- Better control over shadow maps. IE) draw distance, cascades for softer shadows, etc.

 

 

I'm sure I'll think of more, I don't have a ton of experience with Babylon.js yet, but I have many many years of experience in other engines. I did a lot of research on what was available in the WebGL space, and even in a very early state Babylon.js blows everything else out of the water. I intend to add my own improvements for the 'greater good' once I'm ready.

[memomind]

dad72

Thanks for answer \\

 

I know, But i'm just added an idea, I think maybe work in the future 

 

babylon for silverlight 5, I think it old not Update like babylonjs 

 

DLL for javascript, No!, but I'm new in webgl and I'm want high level engine to learn 3d easily, and I will start with babylonjs, 3D Apps for web is wonderful Idea and solution 

 

but I don't know how to use and setup babylonjs and what's IDE I must use it to create 3d apps on web ?

 

And I found babylonjs with Typescript, so i can Use babylonjs with Visual studio 2012 and higher , so how to setup Typescript for visual studio 2012 and setup and use babylonjs with TS?

 

Thanks again brother 

dad72

[Dad72]

@ Testure. Be aware that babylon is still young and evolves very often. He can't see in 1 years features an engine that has 5 or 10 years.

But if you can contribute to the changing also, it'd be great. the engine needs person to contribute to do so going forward.

 

@memomid: Never babylon.js not support dll and winform is impossible. browsers do not use dll to display a web page or 3d browser.

Your idea is specific Windows application, babylon.js is not destine to make a windows application.

[reddozen]

testure,

 

I's actually 4 lights per mesh. You can have as many lights as you want.

[testure]

 

@ Testure. Be aware that babylon is still young and evolves very often. He can't see in 1 years features an engine that has 5 or 10 years.

But if you can contribute to the changing also, it'd be great. the engine needs person to contribute to do so going forward.

 

I'm well aware of how engine development works 

 

This thread is titled "What do you want in babylonjs", so that's what I've enumerated. You'll also notice that I mentioned improvements that I've made that I intend to contribute to the engine.

 

 

testure,

 

I's actually 4 lights per mesh. You can have as many lights as you want.

Oh, I know- perhaps my wording was strange.

[GameMonetize]

@TEsture:You can parent a camera to a mesh, or even a camera to a light. Particle system has an emitter which can be parented to anything.

@TEsture:For particles, you can provide your own function to create and move particles. using color1/2 and colordead you have control for color over lifetime, also randomized rotation angle at spawn is already supported. Same thing for emitter offsets.

 

BTW I added "custom shader" for particles system in the roadmap

[JCPalmer]

testure,

 

As far as deployment with binary format, I think I saw this was mentioned as a do to a while ago.  Of course, you can always put gzip on your web server.  If transmission size is your main concern, sticking with text format & gzip sounds more attractive, with no compiler/loader code maintenance costs by someone too.  I personally have abandoned the scene as data approach for scene as code module, using a Blender exporter I call Tower of Babel.

 

I am also thinking about stuff in the time area.  Am working on a mesh sub-class, I call automaton.  It is for mesh deformations over time, supplied from Blender shape-keys.  Deformations are also coordinated with mesh positioning & rotation.  In development, it would be handy to slow things down with some kind of global setting.  Thinking further, if there were an exception capability, then it could be used beyond dev for some kind of "super-fast" power.  It would actually slow everything else down, but done at the system level, rather than application.

 

If you are planning on writing stuff you intend to contribute,  I would just declare what you plan on doing.

 

Jeff

[testure]

Deltakosh: are these in the latest stable build? or in a beta version? I'm using 1.12, and I don't see any way to randomize rotation angle at spawn, offset the emitter location when attached to an object. I know that emitter can either be a mesh object or a point in space- I'm talking about a combination of the two. Using a mesh object and then making a local offset rather than using the mesh's pivot point as the emission point. 

 

using color1/2 and colordead you have control for color over lifetime, also randomized rotation angle at spawn is already supported. Same thing for emitter offsets.

 

This isn't exactly what I mean- yes you have control over the start and end colors of a particle, but in any modern particle system you're able to use multiple colors along the lifespan of a particle (this is a feature I've recently added in my own project). For example, you want to make a fire particle in babylon currently, you can specify a randomized start color, let's say red or yellow, and then a dead color. so red/alpha zero. This looks nothing like fire A rudimentary fire emitter would start with something like a light blue at t=0, then around t=.25 it would interpolate to a yellow, then t=.6 it would be orange, then t=1 it would be red with alpha zero. In that example t is just a 0-1 scalar representation of the particle's lifespan (however long it may be). 

 

It's worth noting that the example I just used could theoretically be made in babylon as it currently exists, but you would have to layer up several particle systems that would add a lot of unnecessary overdraw, vertices, and boilerplate code to set them up.

[GameMonetize]

Yes this is in the stable build

 

To define rotation angle: minAngularSpeed and maxAngularSpeed

To offset emitter location: minEmitBox and maxEmitBox

[testure]

@TEsture:You can parent a camera to a mesh, or even a camera to a light.

right but the behavior is weird. If you parent a camera to an object, and then have the camera lock to that target, you end up with an additive effect where the camera is looking somewhere else entirely. Also I just tested parenting a light to a camera, that didn't work. Parenting a light to a mesh didn't work. The point I was trying to make is that there's functionality across the board that is inconsistent. Even the fact that a mesh uses .parent to attach to another object, but a particle system uses .emitter to achieve the same result is just confusing for people who are trying to adopt the engine.

[GameMonetize]

If you find bug, just provide a repro case or even better a pull request to fix it. Light should works when parented to a mesh, Same for a camera.

 

Here an example of a light attached to a camera:

http://www.babylonjs.com/playground/#1BV0XY

[GameMonetize]

parenting and defining an emitter is not the same thing. The emitter can be a vector3 or a mesh. So this is not the related to parenting

[Temechon]

Keep the context when calling onAnimationEnd in animations

 

In an animation, would it be possible to set the context when calling this.onAnimationEnd() ?

For example, I have a class 'Piece' with a method Piece.prototype.setRed (setting its color to red)

 

I want to call this method when a specific anmation is finished, so I do something like this : 

var anim = // create animation...this.scene.beginAnimation(this, 0, 100, false, 20, this.setRed);

However, this.setRed will never be called, because of this code in babylon.js :

if (this.onAnimationEnd) {    this.onAnimationEnd();} 

'this' is the Animatble object, and not my Piece object. It could be cool to do something like this : 

if (this.onAnimationEnd) {   this.onAnimationEnd.call(this.ctx, null);} 

What do you think about it ?

[GameMonetize]

I'm not sure to get it. Why do you say "this.setRed will never be called" ?. It should be called AFAIC

[Temechon]

The function called will be: 

 

this (the animatable Object) . setRed () ==> undefined is not a function

 

instead of : 

 

this (the piece Object) . setRed() ==> color changed

[GameMonetize]

Could you create a playground quickly? I'm not sure to get it

[AlexB]

I would like the Blender exporter to only export selected models into the .babylon file. As far as I can tell, it exports every mesh, even meshes set to hidden or placed on other layers. Ideally, you could have a checkbox that says "export all layers" and "export hidden meshes". Perhaps even "export lights" and "export cameras" as well.

 

Thoughts?

[Temechon]

Could you create a playground quickly? I'm not sure to get it

 

Nevermind, I found my problem (my bad)... Here is the fix : http://www.babylonjs.com/playground/#OWNYO

 

I was calling (does not work, I don't get why):

_this.scene.beginAnimation(_this, 0, 100, false, 2.0, _this.setRed);

instead of (works) :

_this.scene.beginAnimation(_this, 0, 100, false, 2.0, function() {_this.setRed()});

Thanks anyway.

[GameMonetize]

I like the "export only selected" features for both max and blender (added to the roadmap)

[JCPalmer]

I would like the Blender exporter to only export selected models into the .babylon file. As far as I can tell, it exports every mesh, even meshes set to hidden or placed on other layers. Ideally, you could have a checkbox that says "export all layers" and "export hidden meshes". Perhaps even "export lights" and "export cameras" as well.

 

Thoughts?

Implementation wise, exclusion checkboxes for meshes / lights / and cameras is the easiest method.  It also provides the most control.  Having .blend wide custom properties might be difficult and / or need to be placed in a odd location in the UI.

 

It appears that you may create your own "dialog boxes" which might be shown prior to the output file chooser, but the knowledge that this exists is all that I have.

[GameMonetize]

New feature pushed to repo: New "Export only current layer" added to blender exporter

[AlexB]

Thanks!

[tumira]

Support for CocoonJS and Ejecta.

[GameMonetize]

I would love too but I do not know what supporting CocoonJS and ejecta implies

 

For Ejecta, I think this is already working correct?