I am having some trouble altering the relative paths to Workers, and Assets when working with Meteorjs (meteor.com). I am trying to use the following directory structure:
./client/compatibility/{Cesium.js, Widgets}
./public/{Assets, Workers}
Meteor includes all js and css files in /client/compatibility, and serves files in ./public as regular files. If I copy everything into client/compatibility, Meteor includes the workers, and can’t serve the assets, and things break as expected.
Just to get something working, I edited Cesium.js and changed the replaced ‘Assets/…’ with ‘/Assets/…’, and ‘Workers/…’, with ‘Workers/…’, and I was able to get the star textures working, and a blank circle that I could rotate. However, the console complains that it wasn’t able to include the workers.
Can someone please guide me on a better way to edit the relative paths to Assets, and Workers? Should I try editing the Source from github, and then rebuild?
Thanks for reading!
You might try to redefine the javascript global CESIUM_URL, even though I’m not quite sure it’ll work (see Cesium.js) 
Thank you! I’ll give that a try. I’ll post back with any positive results
I’m not familiar with Meteor, but what prevents it from loading Assets files from the client/compatibility folder? They’re just files, just like the .js and .css files.
If you do need to work around some strange limitation within Meteor about where files can go, you can customize the location of the various assets in your code. For example, when you construct the Viewer object, you can pass in a SkyBox object which is configured to use the star images from a different location.
For example:
var skyBoxBaseUrl = imageryUrl + ‘SkyBox/tycho2t3_80’;
var viewer = new Cesium.Viewer(‘cesiumContainer’, {
skyBox : new Cesium.SkyBox({
sources : {
positiveX : skyBoxBaseUrl + ‘_px.jpg’,
negativeX : skyBoxBaseUrl + ‘_mx.jpg’,
positiveY : skyBoxBaseUrl + ‘_py.jpg’,
negativeY : skyBoxBaseUrl + ‘_my.jpg’,
positiveZ : skyBoxBaseUrl + ‘_pz.jpg’,
negativeZ : skyBoxBaseUrl + ‘_mz.jpg’
}
})
});
I was trying to do this as well. It seems like these real-time javascript frameworks would apply fairly well to getting something with Cesium up and running. I ran into the same issue, but may try out Sails.js as well.
As for Meteor and Cesium, not being super experienced in Javascript makes this seem like there are two different paradigms battling each other. They are both large and complicated, so it is hard to figure out what the issue is. For Meteor, they load things based on hierarchy and/or naming, unless you define a meteor package. Defining a Cesium meteor package would be the best way to handle this, but the way Cesium is put together is a bit confusing and large.
I was getting errors in where it is looking for cesiumWorkerBootstrapper in the compatibility folder. If I put it in there where it is looking, it then is looking for one another directory down, and so on. The initial directory it complains about is: client/compatibility/Workers/cesiumWorkerBootstrapper.js. I was able to see that following the suggested approach the textures were loaded, however. I ended up modifying Cesium.js wherever it referenced cesiumWorkerBootstrapper, and moving that entire directory under public, but that didn't work.
Later on I was messing around and trying it with Firefox to see if I could get anymore insight and I got this error: Error: WebGL: A texture is going to be rendered as if it were black, as per the OpenGL ES 2.0.24 spec section 3.8.2, because it is a 2D texture, with a minification filter requiring a mipmap, and is not mipmap complete (as defined in section 3.7.10). I always just end up with the black globe with the glow around it.
Another common error is that I see a syntax error thrown in regard to cesiumWorkerBootstrapper, pointing to the meteor file that meteor actually serves to the client. It seems that meteor takes all of your packages and then creates a single HTML page that contains the in order list of javascript files to download. See that here: http://pastebin.com/raw.php?i=dzPGdTe8
My experience with require was on a much smaller scale and took some getting used to, so seeing the main.js file in the require-based release is a little mind boggling.
From looking at your pastebin, it looks like putting files in client/compatibility won’t work for the Workers folder. Those scripts are designed to be loaded using the Web Worker API, and they won’t work if they get dumped onto the main page.
I tried putting everything in public but the cesiumWorkerBootstrapper keeps providing the error and pointing to first character (<) of the main page. I was able to get it loaded up and working with Angular and Sails in a bootstrap dashboard-like page, but haven't addressed the web sockets/model side of things yet.
Hi,
did any of you got this to work?
Thank you!.