Posts Tagged ‘renderer’

Sunday, April 25th, 2010

A new Javascript 3D Engine that can render to Canvas and SVG has been released by mr. doob.

Mr. doob is a well known Flash developer that has added many great experiments and cool contributions without being stuck to one technology, making some great interactive projects in javascript, chrome experiments and html5 (canvas/svg) in addition to the work in Flash with toolkits like Papervision 3D.  Recently the Harmony html5/javascript sketching project generated lots of interest for an html5 sketching app.

Three.js is great because it is a 3d engine built with renderers in SVG and Canvas makes to a really good base for modular, cross platform 3d engine right now (as soon as IE9 joins the party). For a while a good javascript rendering library will need to support multiple renderers for browser differences in performance and supported dependencies like canvas, svg and webgl. Three.js has that reality as part of the design.

Currently the engine only supports particles and triangles/quads with flat colors. The aim is to keep the code as simple and modular as possible.

At the moment the engine can render using <canvas> and <svg>. WebGL rendering would come at a later stage but feel free to fork the project and have a go.

Although this allows 3D for iPhoneOS and Android platforms the performance on these devices is not too good.

Sample Code:

var camera, scene, renderer;

    init();
    setInterval(loop, 1000 / 60);

    function init()
    {
        camera = new Camera(0, 0, 1000);

        scene = new Scene();

        renderer = new CanvasRenderer();
        renderer.setSize(window.innerWidth, window.innerHeight);

        for (var i = 0; i < 1000; i++)
        {
            var particle = new Particle( new ColorMaterial(Math.random() * 0x808008 + 0x808080, 1) );
            particle.size = Math.random() * 10 + 5;
            particle.position.x = Math.random() * 2000 - 1000;
            particle.position.y = Math.random() * 2000 - 1000;
            particle.position.z = Math.random() * 2000 - 1000;
            particle.updateMatrix();
            scene.add( particle );
        }

        document.body.appendChild(renderer.viewport);
    }

    function loop()
    {
        renderer.render(scene, camera);
    }

Saturday, December 13th, 2008

This is pretty impressive.  This is Moonlight for mono (a silverlight clone in mono.net for multiplatform) running inside of Ogre3D (a 3d renderer) as a material.

Argiris Kirtzidi (one of the developers behind Managed OGRE) modified Moonlight to run inside the Ogre3D engine. You can render Moonlight applications or XAML files inside Ogre3D.

Some details in no particular order:

-Moonlight uses cairo for the graphics. I developed a new backend for cairo that fully utilizes the GPU (through Ogre’s RenderSystem) for rendering. This is completely independent from Moonbeam and can be used standalone.

-Moonlight’s core is a native C++ engine and is not dependent in Mono. It is flexible enough to be scripted by anything, javascript, managed code, native code, etc. I’ve got it working on both Mono and the .NET framework and I plan on embedding and trying out Lua for more lightweight stuff.

-If you opt for using managed code, it should be possible, in theory, to utilize the silverlight controls, develop a silverlight widget using visual studio and have it run through moonbeam with full debugging support.

-Getting it to work on Windows was no small task as the moonlight team is completely focused on linux, and there doesn’t seem to be much consideration about cross-platform-ness. I think this is reasonable, though, since moonlight is a young project and their specific goal is to implement silverlight for *nix systems. The downside is that it reduces its flexibility, e.g. in order to inject keyboard/mouse events I will have to create and pass to it GDK events or make heavy patches to it.
Hopefully, there will be more push in the future to get the *nix dependencies abstracted away from the core moonlight engine.

Friday, April 11th, 2008

Jono is giving SWFZ to science and the open source devices.

The SWFZ engine is one Flash 3D engine that took a different approach. It is a bit early in its technique used but the author at custom:media Jono has decided to float the source code out there in ghost mode (no active development but not dead). It is just ready to branch and others to run with it. He is floating the source but I think in 1-2 years this will be the preferred method if processors and multicore parallel usage is optimized. We shall see.

The implementation method and difference with SWFZ engine in Flash for 3d is that is is a pixel based renderer or scanline. It is based on a really fun game engine called Irrlicht which has been pretty active for the last few years but is a C++ DirectX and OpenGL engine. Since SWFZ has to run in Flash and it is a pixel renderer/scanline it has some limitations currently in Flash. Games and renders have to be fast to pull this off and Flash is limited by the software renderer but as computers get multiple processors and flash player gets better at this then this will be a viable option (it is the same thing that limits Canvas based renderers right now). One main problem with this is you can’t go too full screen the biggest sizes that perform well are smaller windows 320×240 etc. But if the processors can handle it it is actually more efficient when it removes overlap, extra triangle drawing and painters algorithm like problems dont’ pop up (triangle overlap when on same plane). This method draws pixel by pixel but fast enough flash engines like Papervision, Sandy3D and Away3D draw overlaps due to the drawing technique, back to front.

But SWFZ still manages to pull off some amazing feats such as these demos

Quake Demo

Terrain Demo

Yoshis Hip Hop Couzin

Jono has put some great classes into SWFZ engine such as bsp parsers, quake md2 parsers, animated mesh, and lots of great examples in porting C++ Irrlicht to AS3. This was a very early example of how AS3 was fun for programmers to port stuff from C or C++ into Flash. AS3 is just fun. Also be sure to check the site for more samples like an FPS game, some basic ai etc.

Jono has been working on 3d in Flash for a while and actually this message is what shows the difference betweeen this approach and other flash engines the way Papervision, Sandy and Away3D (pv3d derivative) make 3d in flash fast enough (Painter’s Algorithm and drawing skewed movieclips and textures.

Demos

More about the Engine Some Notes

The SWFZ engine.

Overview:

SWFZ engine is the result of four years of me messing with 3D in Flash.

I was a complete newbie to 3D, so a lot of learning has happened to get to here.

If you’re interested in 3D engines check out the resource links at the bottom of the page:

The Demo:

Model

  • .md2 format from ID’s Quake2.
  • Uses frame based animation
  • Textured with jpeg
  • No lighting, No Gouraud Shading, just plain texture

Skybox

  • Textures are just jpegs.

Boxes

  • Rendering – Textured Gouraud , Textured Gouraud with Alpha, Textured Gouraud with Quick Alpha, Gouraud Shaded, and the large box is just Textured.
  • Star Texture – Targa (.tga) file format.

AS3 classes

  • 171 classes and interfaces

Scene

  • No lighting
  • No collision detection

SWFZ engine technology:

The demo only shows a small part of the capabilities of the engine. In the coming weeks I will get www.custommedia.co.nz up and running and start to post more info then.

Currently implement stuff:

New file formats supported

  • .tga – Targa Image
  • .bmp – Bitmap Image
  • .3ds – 3D Studio Max
  • .bsp – Quake3 levels
  • .md2 – Quake2 models
  • .obj – Wavefront 3d object (static)
  • .zip – Read from a zip archive (all in Flash, no server side scripts)

3D Rendering

  • mipmaps
  • perspective correct texturing + affine texturing
  • Flat shading
  • Gouraud
  • Textured Gouraud
  • Textured Flat
  • Textured Two Layers
  • Gouraud Alpha
  • Textured Flat Alpha
  • Textured Gouraud Alpha

3D Scene

  • Billboards
  • Parent, Child scene nodes
  • OctTree
  • Skybox
  • Static Meshes
  • Animated Meshes
  • Basic collision detection
  • Scene node animators

If any code is useful to you maybe drop him a donation or what would be nice if this was all setup at google code and used to be integrated into other engines. Irrlicht ports are fun and there is a future in this method when processors catch up I think.