I'm using the SceneLoader to load objects exported from Blender. Each object is exported as its own scene since they each have multiple meshes and a material for each mesh. When I tested the SceneLoader with a single Blender export, it worked fine. However, when I use the SceneLoader multiple times for multiple exports, I sometimes get the following error:
Uncaught TypeError: Cannot read property 'opacity' of undefined SceneLoader.js:1122
I don't get the error on every object, but every time I refresh the page, it happens for the same objects.
This even happens when I create a new SceneLoader for each object. I realize that it was probably not intended to load multiple scenes, but I'd like it to if I can.
Any ideas why this might be happening?
There's two ways to disable the caching which is reported to be the problem in the comment:
Use the incognito mode (it doesn't cache)
In the the Chrome developer tools (the thing with console etc) there's an option to disable caching when the console is open.
We usually use the incognito mode for that at work when doing three.js dev. I figure more reliable as I at least sometimes close & reopen the devtools while developing but tend to keep the same window. The incognito mode looks different so don't make mistakes so that accidentally would start working in a cached setup again.
Related
I have issues with OpenGL ES context loss under LibGDX, so I'm trying to figure out how to solve the problem. My first step was to actually re-initialize all my textures when the resume function is called in one my classes that extends Screen. Like this:
#Override
public void resume() {
Tile.initTiles();
}
The resume function re-creates all my tiles (including their textures), so I thought this would work. However, according to the documentation:
ApplicationListener Docs
The resume function should never be called on a desktop. Now, resume is never called on my Android phone, but on my desktop I tell the program to print "true" to the console in the resume method, and voila, the resume function is actually called on the desktop.
My main questions are:
Why would the resume function be called on my desktop but not on my Android phone?
How can I reload my textures on resume for my Android phone? Currently my textures are white on resuming the game after hitting the back key. Interestingly enough the textures reload fine when exiting through the home button.
I'll quickly explain how I do it, and for me it worked out so far without problems on both desktop and Android.
First of all I use an AssetManager for all my assets, including Texture. I usually load all my assets before entering the actual gameplay screen via a loading screen. But it should also work when you load them in your Screen.show() method.
Whenever I need an asset, the only way I retrieve them is via AssetManager.get(...). My AssetManager is actually a public static member of the base game class, so it can be accessed from anywhere in my code and there is only a single one of them.
In my Screen.resume() method I put an AssetManager.finishLoading(), though I'm not sure this is really necessary.
Right after the game starts and your AssetManager is instantiated, I call the static method Texture.setAssetManager(...).
This closes the circle. When on Android your OGL context is lost, LibGDX will actually revive it for you. Since you've set the AssetManager for your Textures, the manager will be able to find the textures after they have been reloaded. The AssetManager.finishLoading() will wait until the reloading has been finished. After that, everything should work as before the context loss.
Why Screen.resume() is not called, I cannot say. For me it is called on Android. Maybe you need to update your LibGDX version.
I'm using NSOpenGLContext to optimize drawing AU plugins. There are multiple plugins and each can have multiple instances. So each plugin creates a global NSOpenGLContext and attach particular NSView contexts to it, so that the textures do not need do be duplicated.
Problem: When I open one plugin, it's ok. I open a different on, it's ok. Now I release the first one, it destroys all resources => the second one looses its textures!
I checked that both context are different, sharing is different, they both use makeCurrentContext in both lockFocus and drawRect. Any ideas what is wrong here?
Btw.I got the same thing working using AGL and WGL (on Windows), both without problems, so it is just Cocoa as usual.
Ok I think I found a solution - one needs to call [NSOpenGLContext clearCurrentContext]; after any painting or any processing. Why? No idea... I'm considering it yet another bug in Mac OS X...impossible pseudosystem...
For some reason when I use Chrome to test out my website, no images load at all, not even tiny ones like loading icons or the simple "back to top of page" arrow icon at the bottom. The browser tab just hangs on the spinning circle loading state. If I refresh it like 10 times or something then a portion of the images might load. Interestingly my Nivo-Slider images never load... there is a large empty space at where the Nivo-Slider gallery should be at the top left of my page no matter how many times I refresh.
The console is completely clean of errors if you check.
Can anyone check for me why my website is not working in Chrome? It works perfectly in Firefox/IE. I admit some images might have large file sizes but it shouldn't cause Chrome to hang for like half an hour?
I'm using latest Chrome/IE/Firefox. Windows 7 64-bit.
My website: www.symphonyofpromise.com/inspiration/en
By the way my website is a completely fictional museum/gallery project, it's not the official site for some museum!
I cannot be 100% certain on this, but judging from the Network panel, you might be loading too many MP3 files at the same time, thus maxing out the number of simultaneous requests. Chrome might use a different prioritization algorithm.
I would recommend removing some of those MP3 files and deferring loading until after the initial load.
EDIT:
Nevermind that, it appears that the MP3s load fine, but other resources are definitely blocking it. A request should never be pending this long. Poke around further in the Network panel and you'll find the problem.
I have been developing a media player browser plugin for the past few month using Firebreath, but I do not think this is a Firebreath problem.
Currently I am stuck on this weird problem that occurs when one tries to reload the webpage containing the plugin. The image that was being displayed before the reload will stay stuck on the top of screen. The new reloaded plugin will be alive and well behind it but the old image will stay stuck their on the screen forever. If I scroll or resize the browser or even change URLs the image will stay put, however If I move the browser the image will follow. The image stays after closing a tab, but leaves when closing the window
Here is a screenshot that demonstrates what I am talking about.
http://i.imgur.com/asB7i.jpg
( I am a new user so I cant post images )
Has you can see I left my plugin's page and went to the Firebreath website and the image still persists.
This problem happens on both windows and linux, much less frequently on linux, and happens when using both directx and opengl. But only happens on chrome.
Just wondering if you, or anybody else, has any thoughts, suggestions, or insights as to what might be happening. I've tried everything including atrocious hacks and nothing seems to work.
Thank you.
Your problem is most likely that you aren't tearing down your directx or opengl context when the DetachedEvent fires. AttachedEvent is the earliest you can set it up, and DetachedEvent is the latest you can leave it running.
I'm trying to grab web thumbnails by using X server to run Firefox in headless (Xvfb) X11.
I am looking for a way to know when Firefox FINISHED rendering and then I can use image programs to grab the windows.
Problem: I can NOT determine when Firefox finishes rendering. All I know is that the status bar should have an output of "Done" once it finishes rendering (IE, as shown in Firefox in GUI).
Can anyone know what can I use to determine whether if Firefox finishes rendering a page or not?
What I did is just sleep 40 seconds but this may not always work.
Environment:
Centos 5.7, Xvfb, Firefox 3.6.23
Shell commands:
Xvfb: 1 -screen 0 1024x768x24 &
export DISPLAY=localhost:1.0
DISPLAY=localhost:1.0 firefox http://www.example.com -width 1024 -height 768
sleep 40 **[ NEED some thing to tell me if Firefox finishes rendering ]**
DISPLAY=localhost:1.0 import -window root example.com.png
pkill firefox
Three methods off the top of my head.
Write your own extension that hooks to window.onload and fires the image grabber.
Write a greasemonkey script that hooks to window.onload and fires an alert. Wait for such alert, then run your image grabber.
Periodically grab the image of the Stop button (should be at known coordinates relative to the window) and analyze its color. If it's disabled, the rendering is finished.
Note that I don't think this can be done with FF 4.x and above easily. This is due to "features" of these versions. My recommendation to you is to use some different browser if you can, like Opera. I did not test it myself yet, but I think it does not have all those flaws noticed with FF. See below.
In your case following solution may be efficient:
Write some Greasemonkey script which adds an absolute positioned rectangle somewhere on the screen.
Let this rectangle flash in a 3 cycle when the page has finished loading: red, blue, transparent
Write a script which waits at least 2 such cycles to complete (so it sees red, blue, something, red, blue) and then do a screenshot with the correct timing in the transparent phase.
This should be doable with X11 and VNC and similar. Sorry that I don't have a better solution nor code I can present here.
I for my part would solve it using EasyRFB which I wrote to solve similar things. However I cannot recommend that to you, yet, except if you are very desparate Genius able to read and understand horrible undocumented code fragments with ease ;)
BTW, thanks for noting the idea of a package which is able to screenshot arbitrary web pages, which makes an excellent use case for EasyRFB. Never thought about this myself before.
Looking at GitHub I noticed, that there are some solutions for taking web screenshots based on Selenium or WebKit. These are certainly good for promotional shots, but they apparently cannot cover the general usecase on how users see web pages.
Perhaps it would be interesting to be able to automate screenshots from arbitrary pages as seen by a Windows 95 IE 4, FF 1 or Debian Potato with Chimera etc. I'll have a look into this ;)
Note that there is another posting on Stackoverflow from me.
There is something I call EasyRFB which I wrote in a mix of Python (core), PHP (small web helpers) AJAX and bash (control scripts). It was tested with XVnc but shall work with any VNC. It somehow is able to do what you want, but beware, it is development code, undocumented, complex and horribly written and may be faulty. You can find it there:
GitHub: https://github.com/hilbix/pyrfb/tree/easyrfb
My old development directory: http://hydra.geht.net/easyrfb/
It was written for following purposes:
Being able to control a remote GUI from a Mobile even in a situation where the Internet connection is extremely slow and extremely unreliable
Complete UI automation / replace mouse by commandline
Automated QA tests, based on what the user sees in contrast to what the browser or some windows spy program sees, in cases where the output needs not to be pixel-color-perfect as well
It was not written to be fast nor efficient nor easy to use nor for others (yet). It works, for me, somehow.
What it does:
is Web centric and gives a AJAX Web frontend to VNC servers, somehow.
keeps a highly compressed .jpg updated to the contents of the screen.
can take lossless screenshots
is able to fuzzy-match templates against the contents of the screen
templates can be Web-edited with edit.html - however this editor is basic, not self-explanatory and not documented at all
Shell scripts can be written which can wait for these templates to match and send commands like keypresses, mousemoves and clicks to VNC
There are some .sh scripts which could help to understand how this is done, but I am not able to publish the really helpful stuff yet, sorry
Nothing is documented and I am not able to explain how to use it. Either you find out yourself or you are lost. Sorry. Better don't even look at it, it might hurt you.
And now to the problems noticed with FF while doing all this:
Newer FF versions fail to properly update the screen. The last version known working correctly at my side was the FF 3.6 series, all later sometimes develop some strange behavior.
For example:
Newer versions now update the status before they update the screen contents.
Also they have such a high CPU and memory demand, that finishing the last step on updating the screen can take some time. On slow hardware (like the NSLU2, never tested) I think it might even take minutes after the Spinners etc. are already in the "finished" state.
So even looking at the spinner to become gray including(!) naive Greasemonkey solutions which notify about "onload()" both fail with FF 4.x and above, because parts of the screen may still not be updated when you detect that it is ready.
Maybe it has only to do with XVnc, perhaps there is a bug in my scripts which triggers all this, but with FF 3.x everything was right and I think, reverting to an old version would immediately solve all those problems seen. (But I already have workarounds in place for all those trouble. But I cannot publish that scripts, sorry.)
It gets worse.
FF 4.x and above apparently delay event processing a bit. So jumping the mouse out of the scrollbar often keeps it highlighted, I think the event does not reach the scrollbar.
On a normal desktop you do not jump your mouse, but my solution is able to do so. The fix is to generate additional, superfluous mouse movement events to have FF do the right thing.
Also I noticed, I really have no idea if it is due to FF or the web pages shown in FF, that sometimes things do not land where they are supposed to be. I never observed this before with FF 3.x though. The trick which solves this is to reload the page. It might have to do with incremental screen updates, but I did not dive into this yet as the retry (automated clicking on the reload button) works for me.