connecting X3D to a state of the art rendering engine
C++ HTML Python CMake
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
Animation export source code to github May 29, 2017
Appearance updates for Ogre 1.10.10: switch to OgreBites::CameraMan Nov 25, 2017
GeoShape export source code to github May 29, 2017
Geometry export source code to github May 29, 2017
Parser port to new Ogre::SceneLoader API Apr 21, 2018
World port to new Ogre::SceneLoader API Apr 21, 2018
apps add OgrePlugin that can be used as a black box loader with Ogre Apr 21, 2018
core
docs add authors copy Oct 15, 2017
examples
reflection
templates export source code to github May 29, 2017
CMakeLists.txt CMake: refactor build and actually produce an Ogre Plugin Jul 19, 2018
LICENSE.txt add LICENSE.txt May 29, 2017
README.md add authors copy Oct 15, 2017

README.md

x3ogre

x3ogre is an adapter of the declarative X3D concept to the Ogre rendering engine. It maps the core X3D Nodes to Ogre primitives and also allows using Ogre resources inside X3D.

The goal is to load X3D scenes while using the efficient Ogre Meshes and more advanced rendering features available through Ogre.

Unlike other exiting X3D renderers, it offers true cross-platform compatibility being deployable to the Web, Desktop and Mobile.

Citing

@inproceedings{rojtberg2017x3ogre,
  title={x3ogre: connecting X3D to a state of the art rendering engine},
  author={Rojtberg, Pavel and Audenrith, Benjamin},
  booktitle={Proceedings of the 22nd International Conference on 3D Web Technology},
  pages={2},
  year={2017},
  organization={ACM}
}

Authors Copy of the Paper

Documentation

There are two declarative APIs available for usage with x3ogre, the declarative X3D and the Ogre Material System

For more details on x3ogre see

Contributing

To get your code into master, make your changes in a new branch and submit a merge request. The acceptance criteria are:

  • separate your changes: only one feature per branch/ merge request
  • no debug output in source code
  • no commented out code without documentation
  • use as little #ifdefs as possible. document why if you do.
  • no project specific files, only examples