getHeightAtCoordinates return wrong value

[JCPalmer]

@dbawel, I do not know why I am this far down in this thread myself.  Firefox, has spell checker checkbox in preferences.  I assume others do the same.  There is no language specified there.  That might be detected at OS level.

On incremental loading, if there is a bunch of stuff right at the beginning, this might actually slow things.  Although, servers keep the socket open for a short while for additional requests, downloading many smaller files incur latency for each packet.  Big files have better throughout an a bunch of smaller files unless latency is very small.

[dbawel]

@JCPalmer -

On 7/18/2016 at 1:32 PM, JCPalmer said:

On incremental loading, if there is a bunch of stuff right at the beginning, this might actually slow things.  Although, servers keep the socket open for a short while for additional requests, downloading many smaller files incur latency for each packet.  Big files have better throughout an a bunch of smaller files unless latency is very small.

This brief comment you provided is currently very valuable for my specific needs, as this causes me to consider the question as to why I'm delaying the optimization of my WebGL scripts and assets. I've needed to integrate more functions to monitor more specific aspects of scene performance, as the amount of data requested as well as how the data is organized certainly should have a substantial effect on scene specific performance. So thank you for bringing this to my attention - although I feel reasonably "stupid" for not applying this simple logic to our scene previously. I've been waiting for a "functionality" benchmark in our development to occur prior to spending the time further optimizing our current app. However, this discussion will accellerate my evaluation and the work required to optimize and improve overall performance; considering many factors of scene functionality.

And just to note: we are keeping our Websocket connection open for the entire time a user is logged onto our server, so I need to also monitor how this impacts our scene performance when utilizing incremental loading. My assumptions are that this should improve performance when using incremental loading - which may simply be a false assumption. And I'm certain that I would have currently overlooked this without you pointing this out specifically, as I have almost too much to consider and to keep track of - since I alone have been - and still am the only developer working on any elements independant of the server (as well as directing the server development), and am overlooking or postponing obvious functional elements for many circumstances and conditions based upon my own perceived priorities. However, we soon hope to have the approved budget to hire an additional full-time developer, which will improve all aspects of our work - providing we hire the right individual. Any chance you might consider a new job opportunity yourself? I was going to post a request if we got the go-ahead to hire in short time; and I know there are several other individuals on this forum that we would be very fortunate to hire, but if you might consider this, then I wouldn't hesitate to work with you and to count our company extremely fortunate. I just thought I'd ask since I mentioned the subject unintentionally in this post. Please write me back personally if there might be any consideration - although we're still awaiting budget approvals.

And again, thank you for your insight.

Cheers,

DB

EDIT: @_ElementoZerO_ - Your English is good - much better than any other language I speak, even my own native English. So please accept our appriciation for your efforts in communicating in English - a language we native speakers can barely manage ourselves.

[_ElementoZerO_]

I'm sorry for my English   I hope to improve soon.

For the incremental loading question, I thought of using it to load the scene at the beginning of grass, however, I will follow your advice.

@dbawel

I remove incremental loading of grass it seems faster at startup time. Another think that I can try is reduce the polygon complexity of grass.

A question, the LOD system not allow to use sprite and mesh? I mean, at max distance, for example, it would be great use a sprite instead a mesh.

 

[GameMonetize]

Unfortunately we do not own the forum

Regarding video texture issue I cannot reproduce it. Thanks to @dbawel I saw it live but not on a way I can use to fix it. So if someone can work out a playground for the VideoTexture bug I promise I will fix it

[MasterSplinter]

@dbawel I'm actually running 2.5 alpha.  All our draw calls on a discrete laptop gpu are running at about 8ms with the exception of Firefox.   However, I think they broke their Webgl implementation because it's taking nearly 60ms a frame.   Aside from some kernel level throttling were very pleased with perfomance.

[dbawel]

@MasterSplinter - It sounds as though you are using an OS other than Android in testing alpha v2.5? However, if you've done any testing using Android, then please let me know what the difference in performance is using FF - as we know that Chrome has consistantly shown several serious bugs running on Android - especially in working with HTML video and DOM evt. calls. So we have not been able to use - and are still unable to use Chrome for our scenes on Android since we rely heavily on HTML video syncing between devices, and Chrome on Android returns a value of 0.0 for this.video.currentFrame() - in addition to issues with many other DOM callback events - for HTML video and others.

Only FireFox has been reliable for us to use in production on Android, as there are issues with other browsers as well - although Chrome has the most WebGL bugs on Android to date. However even if you've only been testing with either Windows or IOS, then your feedback for each or any browser would still be very valuable for us to compare in our testing and for the community as well. So please provide any info you might have so that we might get a handle on existing WebGL issues for multiple OS sooner than later.

Thanks for your input.

DB

[MasterSplinter]

@dbawel this is very disconcerting.  We're running a custom build of alpha that has some optimizations regarding video textures.   The other big change we did regards using the webvr poly fill.  @RaananW and I discussed this for a bit and we ended up implementing the poly fill because the poly fill just worked slightly better.  Even though it felt hacky...

 

Check your js make sure you're at 13ms that gives you the 3ms headroom you need.

 

I put the ban hammer on anything other than latest builds of browsers.  I got support on opera mobile, dolphin, and non stock chrome.  Haven't tested on firedox mobile as I think they broke their Webgl stuff.

[MasterSplinter]

@dbawel be careful with Firefox it's more forgiving with Javascript than other browsers.

[dbawel]

@MasterSplinter - For Android, we've found FF to be the most stable running v2.2 - and only 2.2 for videoTexture performance. Otherwise almost every other browser gave us errors - specifically Chrome which didn't function at all running 2.3 and above. And forget using .OGG or .OGV files, as they are no longer supported on any device in WebGL from our testing. So we only use webm and mp4 for Android (webm is preferred for Android and we call this codec first), and mp4 for Windows and IOS. I sent files to DK today which demonstrate the problems we have been experiencing, and I'm certain he will have an answer very soon. But if you are still using the OGG file format or any version of OGG compression, it is a complete waste of time.

Thanks for communicating your info, and we'll provide you with whatever we find - so that we shouldn't find ourselves wasting any more time believing it is in our code.

Cheers,

DB

EDIT - I just received your comment on FF, and I've been fearful of relying on this - however, in our testing, it has been the most reliable. But we hope Chrome will correct their WebGL issues on Android soon - at least they claim they will, but we're not holding our breath so we are currently directing clients to FF for now. We have tested FF thoroughly, and it has proven to be running very efficiently in recent testing - FYI running version 2.2 only.

[MasterSplinter]

@dbawel Not sure what's going on -- Chrome on the latest Android is our most stable browser.  It's the only browser that we have handling adaptive bitrate correctly.  Edge also works well except there's a redirect bug >:[ --

[dbawel]

@MasterSplinter - I understand the info you are providing us - as Chrome apears stable on Android. However, our latest WebGL application requires video sync between multiple devices and user in real time, as well as other dynamic functionality. And Chrome on Android will not allow us to set and currentTime() for any video format - so we are unable to use for our current app. Otherwise, Chrome works well on Android in most other tests. But if you want to see wht problems we're having using Chrome on Android, then try and get the currentTime() for any HTML video using Chrome on Android. If we didn't specifically require this function and other HTML video functions, then we would still be using Chrome on Android.

And this is not a babylon.js problem, but has always been a problem in which Chrome only returns a value of 0.0 when querrying this.video.currentTime() using Chrome on Android - regardless of video codec. Only FF on Anroid returns the correct video.currentTime().

Cheers,

DB

[MasterSplinter]

6 hours ago, dbawel said:

@MasterSplinter - I understand the info you are providing us - as Chrome apears stable on Android. However, our latest WebGL application requires video sync between multiple devices and user in real time, as well as other dynamic functionality. And Chrome on Android will not allow us to set and currentTime() for any video format - so we are unable to use for our current app. Otherwise, Chrome works well on Android in most other tests. But if you want to see wht problems we're having using Chrome on Android, then try and get the currentTime() for any HTML video using Chrome on Android. If we didn't specifically require this function and other HTML video functions, then we would still be using Chrome on Android.

And this is not a babylon.js problem, but has always been a problem in which Chrome only returns a value of 0.0 when querrying this.video.currentTime() using Chrome on Android - regardless of video codec. Only FF on Anroid returns the correct video.currentTime().

Cheers

@dbawel I haven't tested this independently and wrote the code six months ago.  But, my timer is working fine on my app with Google mobile chrome.

[dbawel]

@MasterSplinter - Do you have the code up and running for a review? I'm very curious as to what you might have integrated to get sync working or even to return any this.video.currentTime() using Chrome on Android. Please let us know if this is available for review, and/or what your approach is in correcting this long term serious issue - as only FireFox has worked reliably and consistantly for us.

Cheers,

DB

[MasterSplinter]

@dbawel have you been able to reproduce this error with a very basic example?  I'd leave Babylon out and just run a simple webgl context.

[dbawel]

@MasterSplinter - I need to build a PG scene, as my scene is too large for DK to work with currently, as well as trying to sort out everything I'm doing in my scripts which might be affecting the display bugs I have using babylon-master version 2.4, and no problems running version 2.2. However, DK just built a PG scene with one mp4 file I have issues with (no format works for me using version 2.4), and his PG scene works fine. So it might be that I'm using multiple dynamic textures in addition to the videoTextures, so tomorrow I will build upon DK's PG scene, and see if I can find the elements which are causing the bugs to appear.

However, if you're asking for a scene which always returns the currentTime() in Chrome as a value of 0.0, this is simple to test; as Chrome consistantly returns a value of 0.0 on Android running Chrome. Regardless, tomorrow I should have the time to build a PG scene to try and reproduce the issues running BJS version 2.4, as DK has viewed the same bugs running my scene on our servers, and I need to try and reproduce the same problems in a simple environment such as the Playground so we might discover what elemet in my scenes are triggering the bugs myself and other users have been finding. So wish me luck, as I hope I don't need to spend hours adding functions to the PG scene to reproduce the bugs.

Cheers,

DB