Mini-Ray Raytracer

[Amiwell]

well miker, you're working on the rendering engine?

[miker1264]

well miker, you're working on the rendering engine?

Yes. Loading vertices from text file was successful. This is the basis for all load from file operations. The original vertices and 3dface data will be stored in a 3DOBJECT struct. It will be used at save time to save 3dsfile, objfile or project scene file (scnfile).

Now the focus will be to improve the raytracer by using test cases "pyramid", "polyhedron" and "utah teapot" with varying numbers of vertices. Improving the raytracer is the next step.

We have a basic raytracer that renders spheres well and it renders polygon meshes composed of triangles somewhat. There are many features lacking and some things it doesn't do well. In order to take it to the next level we need to improve reflection, refraction and transparency for materials like metal and glass with a high degree of realism with better shading.

We must also be able to use picture datatypes to load custom images that convert to ppm to be used as backgrounds or for texture mapping. Spherical mapping, planar mapping, cubic mapping, etc is the process of mapping 2d images onto 3d surfaces of 3d objects in a scene during the rendering process.

If we can do all these things well we will have a first class app.

[Amiwell]

Bravo Miker, you're doing an accelerant job, I think the community will appreciate a lot, we will have our rendering application and this thanks to you

[miker1264]

The raytracer is making good progress. I have added a "objfile.c" module that will open a 3dobject file ( .OBJ ) and store the 3d data in a 3DObject struct. Using "mesh_save" we can then save the vertices and 3dfaces to a 3dmesh text file which the raytracer can read directly. Or using "mesh_add" the *obj can be converted to a "mesh array" which the raytracer can then render.

When I first started the project I had thought about using a "translation module" that would convert 3d object data into 3d vector data to be sent to the raytracer for rendering. But at that time I had no idea how that would happen. Now the framework is coming together. The "filetype modules" such as objfile.c & 3dsfile.c & scnfile.c would act like dataypes. Each would be responsible to load 3d data into an *obj struct & save an *obj into their respective filetype. In that sense each filetype module becomes a translation module for the raytracer to load 3d files.

The filetype modules are also the basis for the future "3D Editor" component responsible for importing various 3d files and exporting to .OBJ or .3DS or .SCN which the raytracer can use. There will be 3 main components for Sun-Ray Raytracer. The first is "3D Renderer" that I'm working on now. The "3D Viewer" is already completed. The "3D Editor" and possible "3D Modeler" are for future development. They may or may not happen.

Another "feature" that may be useful is displaying 3d wireframes using OpenGL. In addition OpenGL Render (quick render) could be useful for quickly displaying 3d scenes. It seems interesting. It may require a new module "wireframe.c" that uses OpenGL.

[Amiwell]

great miker

[miker1264]

What a crazy idea! 

The raytracer that I currently have compiling and working in AROS has a few issues. It's a basic raytracer. It can render spheres just fine but the ray-triangle intersection functions aren't working correctly. So I need to replace those functions with raytracer functions from a working raytracer. But which one?

Here's the crazy idea...

I'm going to attempt what two years ago I thought was impossible. I will convert the RayStorm raytracer engine from C++ to C code and insert it into the simplified raytracer framework that I now have working on AROS.

In reality the "object.cpp" module contains most of the raytracer code so that needs to be converted and brought over. But it will require several support modules as well such as "octree.cpp" and others. It will need several new structs and especially I will need to setup "Raytracer *rt" struct to convey the data from the 3d files to the raytracer. This involves a lot of work so it may take a week or two to complete it.  But I believe it's possible.

[Amiwell]

we hope well

[miker1264]

we hope well

After three hours of troubleshooting I ported the first part.

Project.c is responsible for loading and parsing RSCN-IFF files. These are RayStorm project files that contain 3d data.

The second part will be more difficult. Object.cpp contains the raytracer engine.

[Amiwell]

Bravo Miker I understand

[miker1264]

As I noted two years ago the same is true today! 

Even with a good understanding of how the internal parts of rendering programs work one thing is still very annoying.

Raystorm code is complicated, convoluted and circuitous in nature. It's extremely bloated in so many cases and it's extremely difficult to follow the course of events through the overly complex program. That's still very true even today!

It isn't well organized and it isn't well commented and it's written in C++ to top it all off. Ok, I'm done complaining for the moment. In the process of assembling the AROS raytracer I will make an effort to simplify where possible & add many useful comments.

Rather than follow the complicated RayStorm example with object loaders and handlers for everything imaginable I'd prefer to simplify the Import & Export process. So the native file format of the raytracer will be a modified and simplified OBJ text file. For lack of a better name it is a 3DMesh Text File.

It will contain all the vertices, 3dfaces (triangles) and information about cameras, lights, materials and textures. When importing a scn or 3ds or obj file it will be converted to 3dmesh text format that the raytracer can easily read. And if you are skillful you could write your own 3dmesh file describing an entire scene that can be loaded and rendered. 

[Amiwell]

Miker patience brings, I'm sorry you're finding difficulties on the code

[miker1264]

Miker patience brings, I'm sorry you're finding difficulties on the code

Yes. Some days it's frustrating when things don't work correctly.

But there is the old saying...if at first you don't succeed, then keep trying. 

[miker1264]

It's not a total loss. I learned something recently.

A few days ago while working on the raytracer I was adding a module that was actually an obj file loader that was written in C++ but to my surprise it wasn't that difficult.

When I looked over the code other than a few C++ classes it looked very clean. It was very close to C code. In fact it was C code with a .cpp file extension. After changing the extension to just .c and changing a few classes to structs other than removing some unnecessary opengl code it compiled easily.

So what was this strange form of C++ really? It is unofficially called "C+". It is straight C code that uses C++ classes and with a .cpp file extension. It can easily be compiled as C code.

I like C+ because it's much easier to understand the code.

[Amiwell]

well miker I'm glad you discovered something new