Tag Archives: 3D engine

SUper Easy to Use 3D Engine (Su3De) – Binary File Format Part 1 – Outline

Over the course of the week as I have started work on Su3De, it has become obvious that we are going to need a binary file format for the 3D objects.  In many ways, this file format is at the heart of what Su3De is all about…a simple way to implement 3D graphics in an embedded environment.  The next step was to start investigating the properties of the binary file format and start work on a “converter” that can convert from a common 3D object format to the Su3De binary format, which I will refer to for the time being as the SU3 format.   The overriding rationale for the SU3 format is to create a 3D binary format that is optimized for embedded systems.  There are new 3D graphics engines that are coming that are quite simplified in nature and will be appropriate for simple MCUs (as opposed to the big SoCs found in smart phones and tablet computers – although Su3De will likely find a home here as well).  These new 3D graphics engines (and the older smaller OpenGL ES 1.1 ones) will benefit from Su3De and its simplified binary 3D object format.


OK…so what are some of the objectives?  First, we want the format to be efficient for embedded systems.  That means that the format should be appropriate for being:

  1. Read as a file from the file system
  2. “Included” as a .H file into the graphics application’s code
  3. Stored in memory (Flash) at a set location / offset
  4. Beamed in from “outer space” – in other words it could come from anywhere – over a network link, for example

You might be wondering, why create a new file format? SURELY there must be a 3D file format that would be suitable for use without having to create something new.  I was actually hoping the same thing, but the only file format I could find that I thought might be appropriate is the .MOD file format which is a binary version of the Alias/Wavefront .OBJ file format (referred to from now on as simply .OBJ).  The problem is that the .MOD file format is proprietary and mostly undocumented and we aren’t really after a binary representation of the .OBJ file format anyway…but rather an extraction and reorganization of the data inside of the .OBJ file format…so a new file format it will be.

The first consideration was whether or not we should simply do an “on the fly” conversion and allow the Su3De user to just import an .OBJ file directly.  I quickly ruled this out, however, because it didn’t make a whole lot of sense.  Any “up front” conversions you can do to reduce processing makes a lot of sense and having the converter as part of the engine will add some fairly significant overhead.  Additionally, if new 3D formats get supported down the line, the Su3De engine will have to change to accommodate the new format(s).

2 ASCII or not 2 ASCII

Next, why not use an ASCII file format?  This would mean that you could conceivably (if you were a mutant) open a notepad app and type in a 3D object line by line.  Also, the object would be “human readable” and quite portable.  While all of this is certainly true, ASCII is an inefficient way to represent a 3D object inside of an embedded environment.  You immediately have to do all kinds of parsing of the ASCII data and then perform string to int, string to float, sting to ??? conversions and then BUILD the 3D object in memory (which would have to be dynamically allocated…meaning DRAM) for use.  You would lose any benefit of storing a bunch of 3D objects in flash memory and using them directly without doing any conversions.  So ASCII is not in any shape or form ideal for this kind of thing…so a binary file format it will be. I suspect that the data will also be much smaller in binary form than in ASCII form as well (yes, yes, yes you CAN compress ASCII data quite nicely…but then you have to add a decompresser to the Su3De engine and you still have all the ASCII related problems I outlined…so just drop it).

Decisions Decisions

This means that a few decisions have already been made (which is nice).

  1. There will be a converter application that will convert .OBJ files to .SU3 files.  This converter will ideally run on Windows, Linux and Macs.
  2. The  .SU3 file will be a binary format (as opposed to an ASCII format)
  3. The  .SU3 file format will be suitable for file system, direct flash memory storage, and include file use and will be immediately useful to Su3De without any further manipulation or conversions.

The two key pieces of information that the .SU3 file will carry initially are vertex and texture coordinates.  Additionally, triangles will be the preferred geometric mesh format – ideally suited for most OpenGL or basic 3D environments.  Each triangle in the 3D model will have three vertex coordinates and three texture coordinates.  For “shaded” 3D models, the texture coordinates will be absent and some kind of color information will be required – unless we pick some solid color to represent the 3D object as a “fallback” if the only data in the .SU3 file is geometry data.  This will be decided later.  Obviously, the .SU3 format will be “expandable” in some manner so we can add things like material information and normals as needed.  Since the “winding order” will be correct in the .OBJ file to begin with, when we create the vertex and texture coordinate lists for each triangle…the winding order will stay correct (kind of obvious isn’t it…but still worth stating…)

OK…so no actual code THIS post, but we are getting there. The next entry will discuss the .SU3 format in a little more concrete detail and will highlight some of the technical issues that we have run into along the way.  Should make for interesting reading…so stay tuned!

SUper Easy to Use 3D Engine (Su3De) – Project Start

Suede 3D Engine

So, I have a need for a VERY simple to use 3D engine for embedded systems and I have decided, after months of vacillating on the issue, to write one. It will be Open Source and the pieces will be published here as well as Source Forge. The engine will sit on top of three 3D architectures initially. OpenGL ES 1.1, OpenGL ES 2.0 and the Fujitsu V03 graphics access library for the Fujitsu Jade “MB86R01″ SoC. It will be developed entirely in ANSI ‘C’ and the goal is to make it abstract enough that it can move to other platforms like Direct3D with ease – but we will see.

First, the name. Every project must have a name. This one is “Su3De” which is an extremely FORCED acronym based on the phrase “Super Easy to Use 3D Engine”. It will, of course, be pronounced “Suede” and I will not use a cow for a logo…although cool cow textures might be sprinkled throughout some of the code samples…just because.  Who wouldn’t love a cow textured tea pot? Don’t judge.

What will make this 3D engine “easy to use”? The API. The plan is to make it as simple as possible. This means a lot of work will be done underneath the API to simplify things. Most of the work will be focused on two main categories.

Loading Objects
Transforming Objects

The plan is to have simple and obvious API calls like Load3DObject(), Rotate3DObject(), Translate3DObject(), Scale3DObject(), etc. Other API functions will be related to things like render contexts and housekeeping.

One of the “tricks” in developing Su3De is going to be in compositing 2D and 3D images together to form a scene. The goal is to do this efficiently and determine a way to do it so that you aren’t rendering the entire scene for every frame. I plan to rethink the way 3D engines work and will likely be bucking convention in several key areas – especially in the area of “Z” ordering – which is the “depth” component of the objects that are being rendered.

Initially the 3D object file format that will be supported by Su3De will be .OBJ files. After that, we will see where it goes. I also plan to support 2D file formats starting with .PNG – both for 2D “objects” as well as 3D object textures. 2D objects will be loaded and rendered as two polygons forming a square with the .PNG as the texture map.

There are many features in the Fujitsu V03 graphics access library that I will want to take advantage of, like using live video as a texture and the layering features of the display controller. These features are extremely useful – but aren’t present in the standard OpenGL APIs…so I will have to balance these somehow.

At any rate, welcome aboard. I hope you find the project interesting. Feel free to comment and tell me what you are thinking as I move forward. It is likely that I will barge forward and run straight into a brick wall and have to back up and change course from time to time, so be prepared for that. It should be fun… See you in Su3De! First “coding” post should be next week sometime. I am a big fan of the Processing Environment and will be using it to “prototype” the code and the initial APIs. Please download it and follow along! See you next week!!!!