Zoom and Rotate Sensibility

[Nastro]

Hi Everybody,

I develop with Babylon.js for a few devices like Tablets or Smartphones.

I using ArcRotateCamera.angularSensibility and wheelPrecision. It's ok on my computer, but no working on Smartphone or tablet :/ 

I using 2.4 Beta version.

With 2.3 version the angularSensibility is ok on my Smartphone.

Any ideas ?

Thanks

Nastro

[Nastro]

Ok sorry i found the good parameter to zoom precision on tablets or smartphones. It's pinchPrecision

[GameMonetize]

Excellent  Thank for answering your own question

[dbawel]

Hi @Deltakosh,

I've done my best to take the time to review the new build 2.4 of babylon.js. However, as DK and @davrous are generally the main organizers and certainly substancial contributers to every new build, what are the main performance improvements and advantages in updating to version 2.4? I'm always overly causious to adopt new builds, and have always been required to do a technology lock for product release at some point. I haven't yet had any issues with babylon.js builds for compatability, but as many people say "If it aint broke, don't risk breaking it." But since there is almost always a performance boost with every new release, and not simpy added functionality, what do you think the primary benefits are to version 2.4?

And I would appriciate hearing from anyone who has contributed to the latest version as well, as I truly appriciate all of the hard work done by so many everyday to make this the best framework I've ever worked with.

FYI - we finally ship the beta of our multiuser real time design app to Weta in 2 weeks (if all goes as planned.) I am in the middle on a substancial re-write of the structure and architecture of the app, and all appears to be going well. But the really great news is that I spoke with Richard Taylor and Peter Jackson late last week, and they are both extremely happy to publicly endorse my company and app, as well as my request for them to publicly endorse babylon.js. In the app itself, on the about page I'm listing "powered by babylon.js" and making it very clear to the public that I could not have ever produced such an app with so much functionality and usability without the babylon framework and this fantastic community. So it is a huge priority for me to do whatever I can to help grow this community; and I believe that a public endorsement for babylon.js by individuals like Peter Jackson, Richard Taylor, and Jim Cameron will help promote this framework to a much wider audience. Variety magazine and Entertainment Engeneering magazine among others will be writing articles with substantial focus on the app, technology, and specifically the babylon.js framework when we release to the public in approximately 120 days. And this will definately be read by millions of people as Pete and Richard don't often endorse technology specifically. So I believe this is quite an exciting time to be a part of the future of entertainment applications which is WebGL, and more specifically Babylon.js.

Anyway, enough of the sideline here, as I I'm writing to ask all of the large brains and super users on this forum (you know who you are) to sum up your personal thoughts on the advantages in performance in adopting babylon.js V2.4. We're currently locked into version 2.2, however I'm quite eager to impliment version 2.4 prior to our beta release.

Thanks,

DB

EDIT - I should have started a new thread for this, however if the visibility is not substantial for this post, then I will definitely do so as a discussion specific to performance by many key contributers and users on a single page should benefit the community overall - at least in my personal opinion. Thank you.

[GameMonetize]

So first: Thanks for asking for Babylon.js!! We desperately need this kind of support!

Back to your initial question: My TOP priority (ask all contributors about this, they will all tell you that I'm really picky with it) are performance and compatibility.

If I have no choice, I sometimes accept breaking changes but this is EXTREMELY rare.

If you look at the what's new of 2.4, you'll see that there is almost no breaking changes:

https://github.com/BabylonJS/Babylon.js/blob/master/dist/preview%20release/what's%20new.md

Big features of 2.4:

- PBR is now a core component

- Canvas2D

- Shader engine improvements (shader includes, unlimited lights support)

- Observables

- Camera input Manager

[dbawel]

@Deltakosh - Thanks so much for all the hard work you and others provide to the framework and this forum. I don't see any issues with compatability in supporting any existing work I've done. I'll at least move to V2.3, however, if V2.4 is stable enough (as generally is the case), I'm hoping to ship to Weta in 2 to 3 weeks time using V2.4. When might you project V2,4 will be release? And I have to tell you that everyone is extremely impressed by the quality of materials and properties when I show them PBR materials. I'm currently building a GearVR demo using PBR, and it is beautiful. By the way, have you checked out the GearVR 3D real time relote camera? As you might know, I'm not a huge Oculus fane, but devices such as this are pretty awesome. I'm looking for a way to produce a demo using the 3D VR camera in a scene using PBR materials, but haven't hit on the right idea yet. However, I need to focus on completing the delivery of the app to Weta asap, as they are patiently waiting to fully introduce into their daily pipeline.

I'm also flying to Wellington, NZ in July if all goes as planned, so if you @Deltakosh and/or @davrous would be interested in meeting Richard and Pete, as well as full immersion in the Weta Workshop and Weta Digital facilities (not to mention Stone Street Studios), then I certainly welcome you to join me there. I believe Jim C. is already there in pre-production for Avatar 2, so we might also be able to expose Jim to babylon.js. However, I haven't spoken to him in over a year, but I'll know his schedule before I travel.

And I'm very interested in any tested benchmarks in performance from any developer on this forum.

Cheers,

DB

[GameMonetize]

I plan to release it before end of may/Early June

 

I would love to have time to go to NZ..but my agenda is a bit overwhelmed

[davrous]

Hi @dbawel. Thanks for your kind support!

I guess my old friend @deltakosh has already answered to your questions. As said, we're paying a lot of attentions to backward compatibility and cross-platform compatibility & performance. It's very rare to have breaking changes. If you're 2.2 based, I don't know any specific that would be in problem in 2.3 neither 2.4. But you know how it goes, please validate that before with some testing

I would love to fly over to NZ visiting Weta. I'm a huge fan of the work they're doing! But I'm based in Paris, it would be a really too long flight for me unfortunately... ;-(

Can't wait to see how you've used our little baby...lon.js

David

 

 

[dbawel]

@davrous and @Deltakosh - Again, thanks for all of your hard work over the years, and for your thoughts on compatability within this post. And as previousy mentioned, if anyone else has executed any benchmark comparisons between 2.2, 2.3, and/or 2.4, then I would love to see specific performance comparisons and share with my small team here. But I suppose it doesn't really matter so very much at this time; unless I run short of time prior to shipping the beta. Otherwise, I expect the next build will only ship with V2.4 as is now planned providing we have time to test and run our own automated QA routines before we ship.

I don't have a flight to NZ yet, but Weta is expected to confirm flights for me soon in late July as I will be assisting them with the integration of the beta app in their daily pipeine, and in addition they are hiring me to build an internal operations and client management application which integrates with our new design app - so that they can follow jobs, resources, and personel internally in real time for swift management divisions daily and throughout each day, week, and month. This will be some basic database development, with some additional functionality and AI to make rudimentary scheduling and resource decisions. I also plan on utilizing babylon.js in their in house app for mobile visualization tools similar to @Wingnut's vision in a recent post. However, the bulk of my time will be working with training and monitoring our desing sharing app with the artists there; as well as to make whatever changes to the app in babylon.js that I can on site to improve GUI and function - since we are just entering the beta cycle with them.

So if either of you (and your families, of course) change your mind in the coming weeks, please let me know. Otherwise, I'll be travelling there more often in the near future, and it's a much nicer visit when they're not entering the middle of Winter - as is the case in July. But I'll make certain it's an open invitation whether I'm there or not, and I promise would be quite enjoyable from what I can discern about the two of you from our discussions and from your work.

Again, thanks for everything, and I expect we can expose a whole lot of nexbies to BJS in the very next future. One of my best buddies @EThomas just joined this forum, and I expect great things from him. But once the articles are published this summer, I would expect a volume of developers and techies to take a serious look at the framework you've built.

Cheers,

DB

[jerome]

@dbawel for the little parts where I could contribute with the core team, I can assure that the performance (on these very parts) is increasing with the versions.

How is this possible ? 

Well, the initial code is usually done to provide a feature to the users : the main goal of the contributor is to fit a requirement.

But by integrating some internal tools after, we sometimes notice (often or not) that some parts can then be refactored and can get some serious optimizations.

Sometimes it concerns the algo itself, the number of steps to achieve a given computation, sometimes it's about a better memory management, sometimes this is about the internal architecture what is rethought to be more efficient. A particular effort is also done to always use the fastest javascript (or GLSL) primitives when something can be done in different ways : efficency over code elegance, ever.  

I have plenty of examples about this : computeNormals() has been recoded 4 times to get its fatest, computeWorldMatrix() has dramatically lowered the consumed memory, every function Mesh.CreateXXX() reduced the memory reallocations to zero on morphing, the SPS had a serious performance improvement under high stress after a refactor, etc.

I had local benchmarks for all these features, I can remember a speed gain of +400% on computeNormals() from the first to the last version.

And I know the other guys that works on the other parts, especially on the shader parts (PBR, Canvas2D) and on the physics interface are in the same punctilious mood to search how to gain every nano second ;-)

 

So generally, if you compare in a stress test or any other benchmark (memory allocation, CPU, FPS) some existing features in older and current BJS version you shoudn't find regressions and may even discover visibile improvements. 

[dbawel]

@jerome,

I generally use the AnTuTu Benchmark app as well as Intel XDK to test new builds and extensions, as well as my own code - but I generally like to try and fully understand (as best I can) the specifcs as to what changes represent the most obvious improvements in performance - especially on mobile devices since this is still so very crucial to today's mobile device development. And in now learning from you that there has been as much as a +400% improvement in performance of some kind based upon the functions to compute surface normals (I assume), this is far beyond what I would have ever imagined. Now I'm truly curious and must look back at all of the builds for the past 2 years to understand each of the 4 different functions for computing surface normals - as there must be much for me to learn from this as well as other recoded essential operations in support of WebGL.

And my appriciation goes out equally to you and others who are contributing so very much to this framework and extensions providing this community with world class functions in the league of DirectX and OpenGL. I'm in conference with the board of Magic Leap this weekend, and am quite eager to demonstrate many of the new abilities of babylon.js, as well as improved compatability and performance, and I'll also be demonstrating a very basic GearVR demo using PBR materials which looks fantastic - even within the Oculus format, which I'm somewhat becomming impressed with the brand and tools in support of this format; as I've never been a huge fan since they spawned directly from my company Emersion Technologies 4 years ago taking with them our military AR tech. However, as basic as it is, I have to admit that there is a branding quality which has been introduced to make Oculus as user friendly as possible, and to provide allot of fun tools and hardware such as the GearVR 3D remote camera, which I now have one sitting in a Pharmacia in Tijuana right now, where I can mentally teleport myself there practically anytime I choose. But that's a whole different subject.

But in support of babylon.js, I'm definately a most dedicated evangelist to the framework; because of developers like you who are as close to the "musicians of computer science"; as anyone I know who is actually making good music and in it strictly for the music - if I can use such an analogy. I'm impressed daily by the dedication you and others demonstrate every day in support of this framework and the users - such as myself who wandered into this forum completely clueless, yet welcomed with open arms.

One of the key developers I'll be meeting with shortly was/is the founder/creator of DirectX and Xobx, and as I've mentioned on the forum in the past, WebGL is still a hard sell. However, I feel I'm making progress on this front, which is the very best I can do to contribute to the framework at this time, due to my limited experience in WebGL frameworks specifically. And I'll let you all know when BJS is supported by notable individuals and groups publicly, as we have several articles in Variety and other publications scheduled later this year for wide release. And you and others will almost all definately get your due, as it is much deserved.

As always, thank you for empowering the community with a framework and tools which in no other case would I be able to develop across most all platforms and make a living doing this. I've never been one who is short on words, although I doubt I will ever do justice to the time spent and the value created to empower us all in the future of online media and visual computation. Please forgive my droning on and on, but I simply cannot help this in not showing my appriciation, as well as helping others with technical issues unique to my experience.

Cheers,

DB

[jerome]

about the function computeNormals(), the initial version had 3 or 4 computing passes, used to allocate 3 big arrays of Vector3 plus some intermediate arrays and used a dozen of Vector3 internal variables. It used to call some external functions for each vertex.

the last version has now only one computing pass and one normalizing pass (just divide by the length). It uses a dozen a internal scalar value variables (floats) and no more js object. No new array at all is allocated.

How to get +400% ?

Well, build a big enough surface in term of number of vertices, say a ribbon, and morph it each frame so that your FPS for instance is 12 FPS with the old function. Check the profiler that all the time is wasted in computeNormals()

Apply then the last function to the same ribbon. The FPS increases to 60 FPS ;-) and recheck the profiler to validate the gain on this very function.

To be honest, this gain was exceptional and I could get it only on a certain range of values on my old computer, at the limit of the CPU bottleneck with the old function (the performance is not linear : once you've reached the CPU limit, the perfs crumble suddenly). But I could reproduce some decent gains (+60 up to +150 %) in many usual cases. 

[dbawel]

@jerome-

I hadn't checked your demo page in quite some time, and the last listed demo "Demo Wall" is awesome. I've been monitoring the CPU on my tablet and an older Galaxy S6, as I knew these would be maxing out the CPU first on a few of the scenes, and can clearly see where and when the overhead hits a performance wall per device and in managing memory. And in working with your's and other scenes, I can now begin to test and to better understand various optimization and memory management functions to increse performance dramaticaly.

Again, thanks for your mentoring of this as it's much more clear to me now as to what requires the highest computation as well as how I should begin to prioritize the management of operations and set threads so that I can minimize waiting times for result dependancies.

Cheers,

DB

[jerome]

thank you D 

oooops, I'm not even sure that the demos on my page are really optimized anyway, I focused rather on the goal or the feature to illustrate

[jerome]

about permanent BJS performance improvements, I'll suggest the most curious of you to have a look at Ben Adams' (+DK) work integrated here : https://github.com/BabylonJS/Babylon.js/pull/1130 for 2.4

This is a deep change, nothing visible neither spectacular for the end user, something like a work maintenance in the sewer. We can't even do a decent PG to show what it's about. And yet ...this will drastically reduce the number of calls to the GPU to do the same operations. In other terms, this will get to a global speed increase of the framework !

[dbawel]

@jerome -

Interleaved Buffers - you're right, this is a game changer for optimizing performance. It'll be interesting to see how this is used by the community and what functions might come out of this other than the obvious. However, I did enjoy the discussion on this thread. Thanks for posting, as I doubt I would have even noticed this development in the computation of verticies, as well as optimizing many vertex properties. I'm glad to see this is in 2.4, and we don't have to wait for 2.5; since this should help me in testing scene opimization for demos I'm working on for the GearVR.

Thanks,

DB