This problem happens recently to me and I have done several tests but nothing seems helpful. So I wonder if anyone has met this problem.
The code that I use and I also put detail description in the document folder
The problem is that after my device have localized in the area (Load ADF on and Learning mode on), the coordinate between the current position and the origin in the ADF is wrong so is the coordinate between the two origins (the origin I start the localization and the one in ADF).
The result shows the wrong coordinates
I've noticed that localization can be done in two different pipeline(usefule note) and I tried another pipeline (Load ADF on and Learning mode off). Yes, it works but I am still wondering why the first one is not working and the differences between the two pipeline (the official website gives just the phenomenon of the two situation but haven't explained why).
I'll be very pleased if you can help me!
I don't know about Java Tango development, but under Unity, when you load an ADF in learning mode (to expand it), the pipeline is different than just loading the ADF with learning mode OFF.
A problem that had already been noticed is that when the learning mode is ON, relocalizing in the ADF is way longer than when learning mode is OFF.
Actually I am not sure about it but what may be the problem, is that when learning mode is ON, TANGO might as well update the base frame of the ADF as new features are learnt. So I would check that out.
Related
I have been wondered about this for several years now. And it comes up increasingly regularly for me (I do mostly product and design some web dev) and now I have some thoughts on how it could be used very powerfully for some new projects but I need to understand it technically. There are some cases where I see still raster images that have had animation added to them on the web, yet they are not video so they can be used with much more versatility and as I understand it with lower performance impact. Riot games uses it frequently, here's is and example on one of their sites. (scroll down to the Agents section with the red background): https://playvalorant.com/en-us/?gclid=CjwKCAiA8OmdBhAgEiwAShr403pomRb6Wqu1mwgbgfR8AbeuJs1FROTT6E_rSZw5QjXu8zNnS61hvRoCvq4QAvD_BwE&gclsrc=aw.ds .
screenshot
I need to understand how the art here was authored and implemented. Can anyone help me learn this?
I inspected it and there seem to be several components that make it up but I can't make any sense of it all. Are people doing this onto something too sophisticated to be common use? I have looked at some animation tools and searched everywhere for info and I'm not finding any clues.
I'm going to have the task to make sure that an animation created for in Unity3D can be run on a Microsoft Hololens. I don't have any further information about the animation yet but I wanted to ask in advance if there are any big things i should keep in mind.
In the animation you're playing a "character" in first person mode, controlled by wasd or the arrow keys and you can look up, down, left, right with the mouse. There are (as known to me) no special interactions besides colliders.
And another question: is it easier to test the animation on the actual hololens or to use a hololens-emulator on my laptop?
I know it's a lot to ask right now without any code or stuff but I still hope that some of you can give me a little advide :)
In my experience it is difficult to say. The HoloLens, besides it is an awesome device with nice specs for that size, has quite limited graphical power. Try to minimize your model's vetices to a reasonable low amount (e.g. using Blender's decimate feature). Set down the quality in Unity's quality setting as proposed in the Dev-Guide.
For your emulation question: The emulator does not emulate the HoloLens' specs (like processor, memory...), but emulates input concepts etc., while running a Hyper-V virtual machine. So the performance in the emulator is dependent to your computer's hardware and is not related to the actual performance on a HoloLens.
Also take a look at the performance guidelines from Microsoft
I worked on HoloLens for a couple of projects. A few points that can be useful for you:
the first big thing I would keep in my mind is understanding if the character has to move in a VR environment. In this case HoloLens is almost useless because its lenses will allow you to see the surroundings [the real ones] distracting you from the virtual world. This is exactly what happens with their pre-installed HoloTour. Nice attempt but you will not totally feel in Roma or Machu Picchu
the second big thing that I would consider is the fact that - at least for the first release - HoloLens has a very limited field of view, that "amounts to the size of a monitor in front of you – equivalent to 15 inches" [source]. It is likely that - in a situation where the character will look in every direction - the objects that you put in the AR space will end up being cut or invisible
about testing: the emulator is really exceptional, I didn't find great differences between it and the real device. Of course if you already have the real HoloLens I would use that. But if not I would first develop and test on the emulator to understand if the project is worth the purchase
It appears that a large fraction of Tango users are experiencing issues since Leibniz was pushed out. I found this post in another thread and thought it might be why I am seeing so much instability in my app after the update:
This is from: TangoService_connectOnFrameAvailable() gets stuck or crashes using Google Tango Leibniz Release 1.10
"Apologies, that you are experiencing problems. Is this still happening? I am asking this because, there was a bit of leeway in timing between when the TangoCore was updated on PlayStore and when the OTA went out (which can potentially cause this issue, if OTA and TangoCore are mismatched). I just want to make sure that you are are updated on both TangoCore and OTA before diagnosing it. Also, make sure you have permissions for camera in the android manifestl." – r4ravi2008
I am pretty sure that the reason I am having problems is because I do have the mismatch described above. I have Tango Core updated through Google Play, but if I got to "About Tablet" I see:
Build number: KOT49H.150320
Also, my Kernel version has an updated date of Friday March 20th.
This build number is exactly the build number referenced here: https://developers.google.com/project-tango/hardware/depth-test
However, on this page it says that this build is for Kalman (not Leibniz). When I try the suggested step of going to "System Updates" and clicking "Check for Update" the system says that it is up to date (even though apparently it did not receive the latest OTA).
Two questions:
Am I correct in that Kernel (OTA) and project tango core are mismatched?
If so, how do I fix this?
Thanks in advance...
Apologies in advance as this is rather a comment than an answer to Voxel Scanner Voxxlr's post... But as I don't have 50 reputation points I cannot leave comments...
Well, like Mark I reset the device to factory settings and carefully updated everything (PlayStore, System Update)... Then, I made super sure that the correct tango_client_api.h/.so is used in my project... Et voila, suddenly it worked... Generally, it seems to be a good idea to spend as little time in the callbacks as possible... Otherwise you can observe these "hiccups" Mark is reporting... After considerable rearrangements in my code everything runs smoothly again... I can also confirm that the color frames are OK... If you are interested in my converter code: I posted it here link
My solution was to use a blunt instrument - force the Tango to do a full factory reset and let it start all over again- I can say that Explorer seems to work fine and the unity pointcloud and tracking samples work, but I'm just getting started and absolutely nothing in this statement should be misconstrued as an endorsement - remember, YMMV :-)
Yeah, no. The Unity Point Cloud sample hiccups all the time with respect to displaying point clouds, and crashes after a minute or two :-(
I believe so, I had similar problems where point cloud and motion tracking would get lost every couple seconds and eventually the app would crash. But just yesterday, my device said there was an update, while previous manual system checks kept saying it was up to date. After updating, the build number lists KOT49H.150414 (Kernel date is April 14, 2015), so that seems to be the actual Leibniz release on the device (not just the Core and SDK), and things are much more stable now.
Also just got the color data and displaying it like an AR image, but it's still in YUV format so everything is red. Working on converting it to RGB, but things seem to be working much better now.
Not sure if this technically qualifies as an answer, but I received this message from Google tango support:
Hi there,
What you are experiencing is a known bug that we have found fix too. Please stay tuned to our next OTA update that will fix this issue. We hope to push this update as soon as possible and thanks for your patience.
Best,
Monty
Project Tango Support
I am honestly not quite sure how to interpret this. What exactly is the bug? That my device won't download the latest OTA? Based on Brian's post, it really does seem that I have a mismatch between Tango Core and the kernel that needs to be remedied to get acceptable performance.
See Google+ Tango Page for info on the issue - there was an OTA update issue - it is being corrected
Can someone explain me why TWebBrowser control is working so slow on all XE editions of Delphi including XE5 and possibly XE6? To test this you need to create a new Delphi project and put TWebBrowser control in it. On form show event, navigate to this website:
http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html
Please test this on Windows 7 or later. When navigation is complete, run setImmediate test and watch the results. It will take huge amount of time to complete the test. It will take about a minute to finish this.
When you open true Internet Explorer browser and do the same thing - test will be completed instantly (~200 miliseconds).
Some additional wierd informations:
When you recreate this procedure on old versions of Delphi (Delphi 7 to be precise) the web-control works as fast as it should be working and test is completed instantly. But the HTML5 speed test will still works slow (alternative test on this page).
Another weird thing is, the same slow behavior can be seen on C++ Builder but not in Visual Studio products. Is Microsoft deliberately slowing down the TWebBorwser in Embarcadero products?? I can't belive this.
I was trying to overcome this problem with diffrent methods such as:
Trying different feature options in registry such as:
FEATURE_GPU_RENDERING,
FEATURE_BROWSER_EMULATION (11001),
FEATURE_ALIGNED_TIMERS (undocumented option),
FEATURE_ALLOW_HIGHFREQ_TIMER (undocumented option),
Setting timerBeginPeriod(1) - no effect.
Please, if someone have any clue how to fix this issue - share this information with me.
UPDATE1
I made standalone test app if anyone cares. It can be downloaded here: http://mp.org.pl/download/ietest.zip It contains source and exe app with htm file. HTM file contains some js procedure that works 10 times faster in standalone IE than in TWebBrowser control. It uses setImmediate as a test (the same procedure used in test described above). But it can be easier for testing this way.
I can also see the behavior described (in your original post and in the comments). I have a few thoughts, but not necessarily an answer.
One should expect some difference in performance between the WebBrowser control and IE, in part because your Delphi app will need to build in support for certain features/APIs that IE supports out of the box.
For example, the WebBrowser control fires notifications related to tabbed browsing (old, but relevant), but it does not intrinsically handle those notifications or update the UI. You have to respond to the notifications and draw the tabs yourself. By default, IE is hardware accelerated and uses certain Windows APIs that may not be directly supported by Delphi's VCL (for resource/performance) reasons. (Hardware acceleration could account for some of the performance differences you've noticed.)
(And, for the record, I don't believe a list of differences between IE and the WebBrowser control was ever documented. I certainly don't remember seeing one in the portfolio.)
Also, the default values for various feature controls vary between IE and applications hosting the WebBrowser control. Part of the reason for this stems from the idea that IE needs to highlight performance over compatibility whereas applications generally need to emphasize compatibility over performance. You may wish to review the feature control reference to see if there are other FCKs you need to enable for your app.
Second, your loops are very tight, perhaps too tight. You've got one request piling on earlier requests and you're not really leaving much room for processing, even with setImmediate. (IIRC, we're not really supposed to use anything smaller than 250ms for setInterval without risking performance hits from the sheer number of requests.) The remarks in the setImmdiate ref. page provide some guidance, as does this article on requestAnimationFrame.
One reason why dragging the window appears to improve performance may due to the priority of window drag repaint requests. They may be forcing your loops to hold long enough (or even break) to allow other events to process. Hard to say without with tracing the system with a debugger.
Have you ever had to add application.processMessages() to your Delphi apps in order to allow the system a chance to handle the work you've already assigned? A similar need may be coming into play given the nature of your test.
Performance testing and timing is a tricky thing. You need to make sure the test isn't imposing so much overhead that it interferes with the actual work you're trying to perform.
Finally, there were some questions about the document mode of the page as it's loaded into your project. When I first started messing around with your sample, I couldn't get project4 to load slowtest.html in anything other than IE5 quirks mode (notoriously slow). Here's what eventually started working for me:
<!DOCTYPE html>
<!-- saved from url=(0023)http://www.contoso.com/ -->
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
<script type="text/javascript">
...
(Note, I deleted your initial doctype declaration and rewrite it to resolve a syntax error that was being reported by the F12 tools debugger.)
A few style key points here:
I used a mark of the web to load the page in the Internet zone. I find this makes it easier to load the page in edge mode, as pages in the intranet zone are loaded in compatibility view by default (unless you map the zones differently).
The x-ua-compatible header needs to be one of the first in the head block. It can follow title, but not much else.
Stylistically, elements need to be specified in lower case these days. There's a possibility that not following the current conventions forces the parser to fall back to an earlier rendering that supports the conventions.
Once I was able to control the documentMode at runtime, I found results I expected: older document modes ran more slowly. I also found that using requestAnimationFrame instead of setImmediate led to even better performance, but also surfaced the timing issue almost immediately.
In the end, this may be a case where the test highlights a problem, but not necessarily one you're trying to solve. (Insert Inigo meme here.) I get that you're trying to resolve a bottleneck. Are you sure you've found the correct bottleneck?
You may not be able to replicate the same performance of the native browser, but perhaps you can refactor the code to perform adequately without the extra overhead? Is there anything that might be better handled with a worker or some other implementation technique?
Hope this helps...
I've Googled around a bit on this issue and haven't been able to come up with anyone else having an issue to this one, so a) I apologize if this is a known issue; and b) I'm thinking this proves that I must be doing something horrifically wrong, yeah? :-)
My application has a very rich landing page which is the first page that is shown after a new launch. It has a panorama control, a large background image (but much smaller than the 2000x2000 limit) and recurring and ongoing animations. Prior to updating my tools to the January refresh, this page ran relatively smoothly. After updating and running the app in the emulator, the background of this page is white (despite the fact that the emulator is on the "dark" theme), performance is quite poor (both in terms of swiping through the panorama and in terms of my recurring animations). When I run the same project on my device, all is well (since, quite obviously, my device's OS is not on the updated image).
Clearly I must be doing something grievously wrong to merit such a cataclysm, but I'm not sure what it might be. I've tried disabling bitmap caching in the places where I'm using it, removing third party tools I'm using such as Peter Torr's awesome tilt effect and his memory usage counter, and several other hail-Mary-style moves, and the problem remains. I also looked through the provided resources and change log to see if perhaps something related has changed, but I didn't see anything.
I'll try to provide example code later if it would be of any use to any would-be saviors out there, but the app is pretty complex and large in terms of lines of code and file size, so it might be a bit tricky. i just thought I'd toss this out there and see if anyone might happen to see it and think of an obvious solution.
Thanks so much in advance for your time and help.
P.S.: I cross-posted this question on the official WP7 dev forums. Sorry if that's against the rules - I'm not a regular SP-poster, as you can tell. If it's a problem, let me know and I can delete the other post.
I was ultimately able to resolve this by creating a brand new project using the updated tools and copying my code, assets, and relevant project settings into it. The app now runs flawlessly on the emulator (or, at least, the flaws in it are my flaws and not the emulator's :-)).
I believe I originally created the project on an earlier version of the SDK, so maybe I had some kind of invalid or incorrect project settings. If I get a moment later, I'll compare the project files to see if I can identify a setting or difference that explains the disparity.
Thanks to all who looked (and to Matt, who even responded :-)). I'll report back if I have any more information that might be of help.
UPDATE: Updating for anyone who might be having this issue as well - my resolution above was a false positive. Creating a new solution and copying stuff in does indeed work, but only until you save and close the new solution. Upon reopening, the problem recurs. Grrrr. I'll post back if I come up with anything else.