Static O3D Dependencies
One thing you might notice when writing your first O3D javascript application are the dependencies which are included at the top of your page:
o3djs.require('o3djs.util');
o3djs.require('o3djs.math');
o3djs.require('o3djs.rendergraph');
o3djs.require('o3djs.primitives');
o3djs.require('o3djs.effect');
o3djs.require('o3djs.io');
o3djs.require('o3djs.arcball');
o3djs.require('o3djs.material');
o3djs.require('o3djs.quaternion');
O3D will use these calls to grab the corresponding script using an XHR request, then write them to the DOM if they haven’t been written yet. This dynamic resolution of dependencies is nice for development, since you can add and remove ‘headers’ on the fly without having to worry about dependencies or modifying your html. The main problem with this method is that if you use o3d alot, the extra requests to your server may seem a bit unnecessary.
My solution was as follows:
- Determine which scripts are written to the DOM and in what order
- Using a makefile, concatenate the files
- Remove all require() calls using sed
- Compress the javascript using Yahoo’s YUI compressor
Determining dependencies
This step is pretty straightforward. Load your o3d application as usual and then use a DOM inspector such as Firebug, or the built in Safari/Chrome Web Inspector, and take a look in your <head> tag. You should see the injected o3d javascript (under /o3djs/):
Injected o3d dependencies
Keep note of these, as they will be used in the next step
The makefile
Using a makefile made the process of concatenating and compressing the javascript extremely simple and streamlined. Here’s the makefile I used to pull this off:
# This is just the root of my static content directory
# you can remove this if you don't need it
STATIC=../../static/
# The folder where the the final compressed
# javascript is installed to after 'make install'
PUBDIR=$(STATIC)js/
# A temporary folder used to store
# generated javascript (the concatenated/compressed file)
OUTDIR=./build/
# Path to the YUI compressor
COMPRESSOR=../yui/build/yuicompressor-2.4.2.jar
# YUI compressor arguments
COMPRESSOR_ARGS=
VPATH=$(OUTDIR)
# Files to copy to the PUBDIR directory on 'make install'
INST_TARGETS=$(OUTDIR)jgblue3d.js
# The location of your o3djs folder
O3D=$(STATIC)j3d/o3djs/
O3D_TARGETS=$(O3D)base.js $(O3D)util.js $(O3D)event.js \
$(O3D)error.js $(O3D)math.js $(O3D)rendergraph.js $(O3D)primitives.js \
$(O3D)effect.js $(O3D)io.js $(O3D)arcball.js $(O3D)quaternions.js \
$(O3D)material.js $(O3D)jgblue-3d.js
jgblue3d.js: combined3d.js
java -jar $(COMPRESSOR) $(COMPRESSOR_ARGS) $(OUTDIR)$< -o $(OUTDIR)$@
combined3d.js: $(O3D_TARGETS)
cat $^ > $(OUTDIR)$@
sed -e 's/^o3djs\.require\(.*\);$$//g' $(OUTDIR)$@ > $(OUTDIR)$@.clean
mv $(OUTDIR)$@.clean $(OUTDIR)$@
.PHONY: install clean all
all: jgblue3d.js
install:
cp $(INST_TARGETS) $(PUBDIR)
clean:
rm $(OUTDIR)*.js
To get this working, you’ll need to change some of the variables to fit your project. The most important thing that you will need to change is the O3D_TARGETS variable. This variable holds base.js, the path to all of the o3d dependencies (gathered in step 1), and finally your o3d code.
Now all you have to do is type:
make && make install
You’re done!
You can now remove the base.js from your html and add the newly generated javascript file! It should work exactly the same as the original**.
** No promises ;)
Hiya Bill and other readers. Interesting stuff here, Bill. I’m wingnut (Larry) in Beesemer MI USA… how ya doon? I hope well.
Hey, have you ever done a “save entire webpage” from the Firefox FILE pulldown… when viewing a o3d? It spews all the JS includes into separate files in the sub-directory of the saved webpage… kind of weird. But, it WON’T go get the o3dtgz file if there was one used in the o3d scene… and it won’t create an assets directory either. (Many of the Google o3d demos pull o3dtgz’s from an assets/ directory… but its certainly no requirement, as we all know).
What’s your opinion of o3d, Bill? I think its pretty nice stuff. That darned teapot is doing something close to raytracing in real time, eh? I see a horizon with clouds… in the teapot’s reflection. Now I’m no coder or 3D modeler, but, from the little time I spent using 3D Max… raytracing was a pretty cpu-heavy phenomena… and its sure good to see it working as nicely as it seems-to… in the teapot demo.
I’ve always seem to gravitate toward dynamics and particle emitting… and, ideally, a mixture of both. In Max, I used to fire up particle emitters (polygon sprayers) and then link them to blowers, gravity, explosions, tornadoes, you name it. FUN, though, again CPU-heavy, especially if you sprayed anything more vertex-heavy than simple primitives or faces… and if you sprayed heavy amounts.
Have ya seen THIS 5-pack of demos?
http://o3d.googlecode.com/svn/trunk/samples/box2d-3d/box2d-3d.html
Left click on those demos, and polygons come flying out of your mouse arrow, and they have weight/gravity… so they tumble and rumble around with the animated o3d objects. Its TOTALLY fun. Especially, the piston. Change which demo… by right clicking. All 5 of the included dynamics demos… allow the left-click polygon emitting. I really got a bit addited and drooling when I played with them.
Ok, I’ll be around, Bill… nice to meet you. Hello to other readers… don’t be afraid to fill Bill’s blog with words… especially about o3d. :) I’m a bit over 50 years old… so I wndt through the VRML phase, and it was plenty fun. But CosmoPlayer never did shadows or chrome… so its a whole new world for me. Now what the hell is a matrix transform again? I forget. :)
Be good!
Wingnut
Anti-Capitalism-ist/Tech Idiot