Tags

redhat
employment
ripple
interfaces
ncurses
ruby
refs
filesystems
retro gaming
raspberry pi
sinatra
3d printing
nethack
gcc
compiler
fedora
virtfs
project
gaming
vim
grep
sed
aikido
philosophy
splix
android
lvm
storage
bitcoin
projects
sig315
miq
db
polisher
meditation
hopex
conferences
omega
simulator
bundler_ext
rubygems
book review
google code in
isitfedoraruby
svn
gsoc
design patters
jsonrpc
rjr
aeolus
ohiolinuxfest
rome
europe
travel
brno
gtk
python
puppet
conference
fudcon
snap
html5
tips
ssh
linux
hardware
libvirt
virtualization
engineering expo
cloud
rpm
yum
rake
redmine
plugins
screencasting
jruby
fosscon
pidgin
gnome-shell
distros
notacon
presentation
rails
deltacloud
apache
qmf
passenger
syrlug
hackerspace
music
massive attack
crypto
backups
vnc
xsd
rxsd
x3d
mercurial
ovirt
qpid
webdev
haikus
poetry
legaleese
jquery
selenium
testing
xpath
git
sshfs
svg
ldap
autotools
pygtk
xmlrpc
slackware

Dec 13 2009 x3d

X3D

X3D (wikipedia) is one of those standards that is going to become very popular because it has a huge feature set or fail into obscurity because it is too large and complex to use. Regardless, I’ve just discovered the specification and have been reading about it / playing around w/ a few implementations over the last few days and I’m pretty impressed.

The cool thing about X3D is that it is a whole 3D scene standard, meaning not only does it encapsulate 3D meshes contained within traditional standards, it has practically everything you want for a 3D world. Lighting, Materials, Networking, Sound, Events, Animation, Scripting, Physics / Collision, and a slew of other 3D scene properties can be described in the X3D format. Of course the trade off for being this complete is the complexity of the standard.

The Draft Specifications and xsd go a long way to (starting to) understand the specification. At its root X3D is fairly straightforward, it is represented via xml files, created with a generator and parsed with a loader. Loaders do not run any of the dynamic / execution time components, rather a browser is used to manage scenes/scene graphs, the complete hierarchical set of all objects known as nodes. Nodes contain descriptive fields and events to manipulate and query the node state.

From there its just different node types which describe different types of components in the system. Components exist for 2D and 3D locations, coordinates, geometry, resources (audio, input, network, etc.), animation, collisions, navigation, organization, etc. Needless to say, alot of abstraction/inheritance is used, component interfaces sometimes expand several levels deep before concrete node object classes are defined. It’s pretty complex but complete.

There are a couple of X3D solutions out there, though the standard proposes many cross platform solutions. X3D aim to be as abstract, and thus as cross-platform/framework/etc. as possible. Solutions exist for C++ (with GTK), Java, ECMAScript (eg javascript), and even a Firefox plugin.

X3D itself is a successor of the VRML standard, the old VRML syntax is still supported as an alternative for xml. It’s a relatively new standard, first approved in 2005, and at the very least an interesting study. I may continue to muck around with it, possibly using it in an new project in the future.