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

[reddozen]

What about subdividing the image into a bunch of smaller terrain pieces within Babylon before the terrain is created, then use something like the tag system to keep them together so it could all be translated together... This wouldn't have to effect the geometry. you could use the same calculated triangles. You would just have some minor vertex duplication at the seam. This could also help with the LOD system planned later making it easier to stitch in the lower detail pieces (could probably even have an optional value on the function to define number of LOD segments, and create them all at the same time). Then maybe you don't have to go over every triangle of a huge terrain to calculate impacts. Would probably have to tie that into the octree support to make sure that you weren't looking at every ground "tile", but I would imagine that you would have to do that for LOD support anyway.

 

It all makes since in my head anyway...

[gwenael]

Nice to read how the tags system may be used

[ahom]

Hey,

Firstly, thank you for this great library! I finally found what I was looking for in babylon as a WebGL js library.

Secondly, what would be pretty nice to have is:
 

1. Handling of DDS files other than compressed types, at least the RGB/A handled by WebGL, gl.UNSIGNED_BYTE/gl.UNSIGNED_SHORT_5_6_5/gl.UNSIGNED_SHORT_4_4_4_4/gl.UNSIGNED_SHORT_5_5_5_1. (I might just PR it next week when I'll work on my fork)
2. Being able to upload different textures at a given offset/size to the same texture via compressed/texSubImage2D. In my case I don' t control the assets and I need to do this in order to skin a  mesh from textures with different compression types (DXT), I could do this offline, but as there are multiple composition configurations I would create lots and lots of textures for this. However, I don't know how much the devs of Babylon would want this in the library, I guess that could just be a new kind of texture that is composed of sub_textures.
3. Are there any plans for being able to define vertex attributes from a vertex buffer containing all data (positions/uv/normals/etc..) concatenated? Basically, being able to control type/offset/stride of the vertexAttribPointer call while giving a big Uint8Array containing all the data.
4. Lastly, is there a way to modify the mapping of attributes from a normal map or some other textures? Funnily enough sometimes X,Y,Z components are not always in R,G,B. I could just write my own shader though.
   
   
   Thanks for your consideration! And keep up the good work! (From another frenchman (~'-')~)

[Vousk-prod.]

What would be very cool is an easing parameter for BABYLON.InterpolateValueAction (like easings in jQuery UI for instance http://api.jqueryui.com/easings/)

[Marco Lebdech]

Hi,

 

as I understand, this is feature-request page. So as We(team) are working on big application in native 3d engine, I am working on exporter to .babylon file for the web-app. As we are loading many scenes, that are not equally structured, we need some sort of variability there. So this is what I found out that I am missing in BJS.

PS: I am using 1.11 exported from typescript for now, i dont know if any of things below is already in 1.12...

1. metadata of object in "userData" property. The best var-type would be Object, as it is the best type for that case. We have so much data saved in unity, which are not exportable into .babylon file for now. It would be simple property of every instantiable object  in file (camera, material, mesh...), For now we need to provide another file with metadata and it means more http requests, more redundancy in data ( when i want to target specific element ) and parsing multiple files.
2. Add "layerMask" property to Mesh and Camera. To implement layers, that are implemented in 3DSMax. Displayed meshes are these, that have (newScene.activeCamera.layerMask & mesh.layerMask) > 0.
   I implemented it with adding 6 lines in typescript and added 1 condition (parsing of .babylon file property included), and saved hours of work on iterating through meshes that i want to have displayed, while having metadata file which defines camera-case-meshes table....

Thanks for reply, if anything is not clear, i will respond through pm...

[GameMonetize]

Hey Marco, you features sound really good. If you already implemented them please make a pull request and I will integrate it into bjs

[Леонтьев Алексей]

Want 2D API for DynamicTexture and select events. Need feature create 2D dashboard.

[GameMonetize]

The DynamicTexture has a canvas with all canvas API:

http://www.w3schools.com/html/html5_canvas.asp

[jiweigang1]

i want to  use it to  make 3d text  and  line     

[reddozen]

I'm not sure why node.js needs to be built in. you can just include it in your project and use the parts that you need...

[JCPalmer]

I mentioned this elsewhere, but if here is where all the requests are stored, place a function in Engine that returns a float of the Babylon version & as well as a convenience function in scene, which calls the one in engine.  The thing about version reporting is that it is always better to be reporting it, before someone needs it.

 

Pretty minor to implement as well.

[GameMonetize]

Done with 1.13

[JCPalmer]

Done with 1.13

This is in reference to Version.  Just made my first non-compatible change (override Automaton.prototype.setVerticesData() to capture positions vertex buffer, and grab the data to initialize a persistent Float32Array after call to super).

 

Working with version is difficult enough, since is does not exist prior to 1.13,  but returning as "1.13.0" is a mess.  Could this not be:

        public static get Version(): number {            return 1.130;        }

Thanks,

Jeff

[JCPalmer]

Fluff,

I do not disagree with anything you said, though I have no opinion on Typescript or DarkBASIC yet.  I am approaching it purely from the "reference in code" side.  Sometimes, I feel over-complicated versioning is just something for former programmers, now project leaders, to over think.

 

What is major?  What is minor? Who cares?  Personally, I have a preference for just an integer 1, then 2, then ...  Barring that,  whatever route is chosen, e.g. large # of digits or IP address,  the API that reports it should break it out into as many parts as is expressed in.  Having to "regex" the thing before it is usable, discourages its use.

 

Jeff

[JCPalmer]

I know I have been asking for many system tools not new features, but since Javascript has no assert facility, how about a BABYLON.Engine.Debug property set to true for the debug build.  Do not know how tricky this would be to combine this with the build type.  Recently wrote something, where doing through checking of function args would be good in test, whether that be system, or application level using a debug build of a production version.  In deployment, these tests would just slow the system down.

 

Example use:

if (BABYLON.Engine.Debug){    if (your failure test here) throw "sorry, you messed up"    . . . }

Of course, you cannot put code in the block that has side effects, but that is the way it is with all implementations of assert.

 

It would also be good, If the debug build could be as unmodified as possible (comments & line breaks not stripped).  Pretty print or not,  these line end up so long,  scrolling in a debugger can make you want to kill yourself.  Saw the suggestion that you could do it yourself, & I'll get there, but think it would beneficial to be part of the normal build process.  This is not a very manual process (hope)?

 

Also saw the options arg to the Engine constructor, but my Javascript is not good enough yet to know to add my own property.  Any help.  Thought options was for user defined Javascript properties for Engine, not options passed to webGL engine .  Never mind on this part.

[Dad72]

The version numbers have a sense. It is a standard that has been proven.

 

         1            .        10           .       100

major Version . minor version . version fixed

 

Named versions 1, 2, 3, 4... has no sense. that is what differentiates the minor version of the major versions or patches.

[JCPalmer]

Making sense, silly humans!    I am not even going to get into the political/marketing influences that seem to ultimately decide what is major or minor.

 

Let me do this another way then:  There is is a need for a static function from Engine, which will return a number which represents the version.  You can still have the major.minor.fix text version, but the function allows for a check that can be done on 1 line, that is not tortured with all kinds of Number(), split(), replace(), substr() or whatever methods  & everybody is happy! There is NO need for it to make sense.

 

If static is not possible, also need a convenience function in Scene, since Engine is rarely passed as an arg.  Thanks!

[JCPalmer]

Hitting 4 billion of anything seems like a bit of high class problem.  Also, not every change to any file or nightly builds need to increment it.  Just production releases, or fixes.  Any developer using beta releases should probably be monitoring boards like this, and weird regressions can also happen in development.  This is primarily for things like features expected that did not exist prior to 1.x.x.  

 

I even could see something like 1.013999 working, allowing for 999 minor versions & 999 fixes (think floating point precision handles this).  Probably overkill.  Would someone even consider using something this small that had 1000 fixes between minor releases, or 1000 minor releases in a row?  I would think they were screwed up, and look elsewhere.

[Paradine]

1. Add unified babylon.1.12.d.ts, babylon.1.13-beta.d.ts etc and if possible you could add it to NuGet. It would make life easier for newcomers, who prefer to use typescript.
2. Add missing .ts and .d.ts for example SceneLoader.ImportMesh does not exist probably because of conflict with filesInput.d.ts file, where class is already defined and typescript does not support partial classes (I think it is good thing).
3. +1 support for shapekeys from lipsyncing sample mentioned before on this thread.
4. Better documentation design for example as here: http://en.cppreference.com/w/

[Dad72]

The documentation should be different for 1.12.

as it is carried out by a member of the community. documentation is not the official.

But I agree that the lack of documentation information. it only shows the classes, members and functions, but does not say what was used and each member function with an example usage for each function and members would be nice.

[GameMonetize]

Anyone can help for documentation. Wiki on Github is done for that specific usage

[Temechon]

I'm sorry, I do what I can on my work time and on my spare time.

 

Moreover : http://www.html5gamedevs.com/topic/5759-exemple-tutoriel-for-new-version/?p=34671

 

RIght after I think I will be able to find a budget for writing a lot more examples and documentation (Hopefully)

 

So wait and see !

[Dad72]

Thanks Temechon for your time on documentation. I am aware that you made that you can. At least we have a documentation, Even if we would like to have a documentation more complete.

 

It is true that Deltakosh had us talking about a possibility of official documentation and budget. What happens to this information?

 

Yes Deltakosh, everyone can help, but if everyone create documentation, it is not necessarily well. Should be that everyone can do evolve one that Temechon to do to keep a single documentation and what is hosted on www.babylon.com.

 

[reddozen]

I think we would be fine letting everyone contribute to the document. Just make it reviewed before posting. make it like editing a post... you can change things in it, and "approve" or "decline".

[memomind]

SALAAM,

 

I have Idea for babylonjs

 

1- make it support .NET platform  as DLL library for ( VB.net, C# Langs  - WinForms, ASP.net, WPF, WinRT, Win8 )

 

thanks, I hope accept this Idea.

 

 

Memo.