AROS Exec

Development => AROS Software Development => Topic started by: miker1264 on June 26, 2021, 08:01:23 PM

Title: Mini-Ray Raytracer
Post by: miker1264 on June 26, 2021, 08:01:23 PM
For the benefit of those, like myself, who are interested in raytracers for AROS this is for you.

A few years ago I looked at RayStorm as a basis for a Raytracer for use with AROS. Fast forward till the present day. I have a new conceptual approach. Hopefully, over the last five years my AROS C programming skills have improved. Also, knowing how I work best to develope new applications this is my proposed approach to the issue of providing a raytracer for use in AROS.

I will do all the research up front about raytracers and document everything. Then I will independently put together a Raytracer Application for rendering 3D scenes. I will use RayStorm as just one part of my research for a more comprehensive approach to raytracing. I will also study 3D Object files (scene files) from 3D Studio, 3D Studio Max, Maya,  Alladin, Cinema, and even Blender.

I have set up a test application called Mini-Ray to help study raytracing. It will be a modular approach to raytracing. I will set up an application with a simple GUI that allows to render a selection of built-in scenes or the ability to load external 3D Object files such as .3DS, .MAX, .SCN, etc. At first it will incorporate just one Raytracer Engine such as Mini-Ray. But eventually it may include other Raytracer Engines such as the Blender Engine. With a modular approach it would be easier to add Raytracers and 3D Object File Readers.

After I do my research and put together the Raytracer Application then the code will be available for anyone else interested in developing raytracers for use with AROS.

Happy coding  ;)
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on June 27, 2021, 12:41:50 PM
Thanks miker all seems very interesting, thanks for your support I think Aros users will be very happy with what you will do again :)
Title: Re: Mini-Ray Raytracer
Post by: serk118uk on June 27, 2021, 01:57:04 PM
Thanks miker1264..
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on June 27, 2021, 03:31:25 PM
Thanks miker1264..

Scratchapixel.com has an interesting article that describes Raytracing.

Raytracing is a method that is based on human perception. It is a series of algorithms (the raytracing engine) that uses principles of mathematics and physics to trace the rays of light from a light source to a series of objects (the scene). The raytracer calculates and predicts collisions of photons with surfaces. It also accounts for textures and materials to predict shadowing as well as reflection and refraction.

The degree of fine detail based on these things determine the quality of the raytracer itself. The 3D Objects stored in Scene Files are loaded into the raytracer application as 3D Vectors.

It's all derived from a complex set of mathematics that predict and calculate 3D Pixels ( voxels maybe) that are then converted to 2D Pixels forming a rendered image.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on June 27, 2021, 05:50:50 PM
very well miker 8)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on June 27, 2021, 09:40:50 PM
I have a complete concept for the raytracer application. I'm satisfied with it.

As I mentioned, a few years ago I was doing research for a raytracer based in part on concepts from  RayStorm. I'd like to re-use much of that for the new project, especially the app icon and the artwork. In a tribute to RayStorm whose initials are R.S. I'd like to include them but in reverse and the word 'Ray' in a new application. So the name will be 'SunRay Raytracer'. The app icon is a gold ball with the word 'RAY'. The Logo is an image of Sun Rays spreading out towards the horizon like a Starburst Symbol on an Amiga Blue Background. In the middle of the rays will be a Star Symbol representing the Sun itself. That's it. SunRay Raytracer.  8)

Since it is basically a Complex Grahics Program that uses a Raytracer Engine to render 2D Images based on 3D Object Files it will in many ways resemble other AROS graphics programs.

It will use it's own screen and it will be modular in design based on MUI. When fist opened the 'Main Module' will appear which will be a Button Menu that is intended to resemble Lightwave ButtonBar Menus. There will be a few important modules including Project Module, Render Module, and Convert Module. Each module can be accessed from the Main Button Menu or from the System Menu. The Convert Module will use Picture Datatypes to convert images for use with the Rendered PPM.

Although the user may select the output image dimensions all rendered images will be temporarily saved as PPM and they will display in a Viewer Window with a separate Menu attached. The temp image must be saved or it will be deleted at render time.

The basic internal scene file format may use the IFF-based .SCN File which RayStorm uses to store 3D Scenes. Other 3D Object Files from 3D Modelers such as Lightwave or Blender can be Imported and saved as IFF-SCN Files. Also, SCN Files can in turn be Exported as 3D Object Files in various formats for 3D Modelers such as Lightwave or Blender to use for rendering.

Attached here is the App Icon.
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on June 28, 2021, 02:54:16 AM
Here is the artwork for new Sun-Ray Logo.  8)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on June 28, 2021, 03:23:54 AM
Here is the first rendered PPM Image from MiniRay Test Program. It is based on 3D Vector Data.

The MiniRay Program will be used to develope and test all the working code for the raytracer.

At the moment MiniRay is only compiled for use with x86. But soon I will compile it for x86_64.

The very fist component to be developed and tested will be the Viewer Window with its own menu. Picture Datatypes can be used to convert the temp PPM file to any supported picture type.

Once the MiniRay Program is sufficiently advanced the functons and components will be moved to the MUI based Sun-Ray Raytracer Application.
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on June 28, 2021, 03:35:53 AM
The Sun-Ray Raytracer Logo.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on June 28, 2021, 01:03:45 PM
I'm happy how work is proceeding, surely there are many users who are appreciating your work :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on June 29, 2021, 12:43:33 AM
I'm happy how work is proceeding, surely there are many users who are appreciating your work :)

Clearly taking on the task of writing a 3D Rendering Program for AROS seems like it could become such a daunting experience, especially when looking at all the 3D Vectors and strange mathematical equations.

I thought I had left algebra, trigonometry and physics back in my school days! Nope. Here it is again. But my philosophy is to start out small with something that works and gradually add complexity and functionality.

Maybe I will learn some valuable lessons as well. Never too old to learn new things!  ;)

As an inspiration to get the raytracer to the point of loading 3DS and PRJ files and rendering the scenes I was looking for my old zip disk archives for my old projects. I had two 3D Studio projects that I remember most. One was KEROLAMP.3DS which was a kerosene lamp with transparent glass. The other was MARBVASE.3DS which was a green marble vase with black legs sitting on a wooden table. I didn't find the rendered Targa images for them. But I found the 3DS Object Files. They are begging me to finish the raytracer so I can save new Targa images!  :) :) :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on June 29, 2021, 06:48:10 AM
That's what I have to reproduce in the Raytracer in AROS.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on June 29, 2021, 11:09:20 AM
well miker :)
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on June 29, 2021, 11:18:20 AM
Congratulations Miker you are doing an excellent job, you never end up learning if you are inclined towards certain attitudes, it becomes a whole game and you have fun, to me Aros puts a smile and I thank those who contributed and those who contribute like you all now both for the development of the system and for third-party programs, we have a considerable music park at musical level for example, we hope to increase it with time, meanwhile thanks ;)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on June 29, 2021, 04:44:52 PM
Congratulations Miker you are doing an excellent job, you never end up learning if you are inclined towards certain attitudes, it becomes a whole game and you have fun, to me Aros puts a smile and I thank those who contributed and those who contribute like you all now both for the development of the system and for third-party programs, we have a considerable music park at musical level for example, we hope to increase it with time, meanwhile thanks ;)

Having a clearly stated goal provides great motivation. I installed 3D Studio R4 in DOSBox to render this Targa Image. It works great and the renders are super fast compared to the original. When I used 3DS R4 in school in 1994 I remember the renders took up to 30 minutes. Now in DOSBox in emulation it takes 14s so I expect a similar increase in the render speed for Sun-Ray compared to Amiga RayStorm or even Lightwave.

Working on datatypes and the like is what I do to help improve AROS. But working on the Raytracer is what I will do for fun!  ;)
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on June 29, 2021, 05:13:15 PM
thank you miker :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on June 30, 2021, 06:37:14 AM
Raytracer Test Program in action. It compiles in C code for x86_64.
Title: Re: Mini-Ray Raytracer
Post by: paolone on June 30, 2021, 09:12:03 AM
@Miker


Great work as usual! Thank you for keeping us updated about this.
Title: Re: Mini-Ray Raytracer
Post by: Argo on June 30, 2021, 09:55:13 AM
Nice, This will be great to have on AROS
Title: Re: Mini-Ray Raytracer
Post by: AMIGASYSTEM on June 30, 2021, 10:12:53 AM
miker great tool, AROS One will be happy to host it   :)

For Mini-Ray Raytracer I made a News on Amiganews.it (https://www.amiganews.it/), i will make it on EAB later, hope you like it. ;)
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on June 30, 2021, 02:31:33 PM
I'm happy miker having fun while you apply to the development of the program :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 01, 2021, 03:59:14 AM
You may think that over the last few days I have miraculously written a complete raytracer that actually works. But in reality that isn't the case. I was prepared to write it from scratch but raytracers are by nature complicated pieces of software. It seems there are many samples of raytracers available, though. However, they are nearly all written in C++ which doesn't fit my needs for a working raytracer for AROS.

Mini-Ray was one such simplistic C++ version of raytracer that contained everything in one module - "raytracer.cpp". I've been looking at that code wondering first how to convert it to C code, then how to expand it to actually render polygon meshes with lots of triangles. Yesterday I discovered a simple raytracer written in C code that seemed to have all the qualities needed.

But there is still plenty of hard work to do to make it into a nice AROS-friendly graphics application. It needs to run from Workbench and it needs a menu system and much more.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 01, 2021, 12:16:28 PM
i understand miker
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 02, 2021, 11:41:39 PM
i understand miker

The raytracer being worked on now I ported from Mac OS (x-code) for use on AROS. Not everything was compatible.

It took about 5 hours to make it work correctly. I must have tried to compile it about two dozen times. It was setup to use Png Library or "cmfts" or something like that for display purposes.

But it wasn't as much "display" as it was "saveToFile. So I re-wrote all of that. Now it uses "ppm_render" which saves directly to ppm which AROS pnm datatype can read. Next I will work on a menu system and try to get the polygon mesh to render.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 03, 2021, 12:46:38 PM
ok miker well, i'm happy :)
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 04, 2021, 02:49:16 PM
Miker are working on an module Raytracer open source?
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 04, 2021, 04:14:14 PM
Miker are working on an module Raytracer open source?

Yes. Salvo.

The Raytracer sources will be available as open source. I'm currently fixing the rendering process for polygon meshes. It seems to be seriously broken! I may need to re-write much of the rendering code to make it work. It's not an easy task.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 04, 2021, 06:47:15 PM
Excuse me but you are working on Raystorm sources or something else
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 04, 2021, 09:46:21 PM
Excuse me but you are working on Raystorm sources or something else

I will likely refer to RayStorm sources as a guide for reading and writing SCN Project Files and for Import and Export of 3DS Files.
For the rest of the raytracer I am using other raytracer sources that are written in C code. That makes things easier.

There is still a problem with rendering 3D Polygon Mesh. It now loads the vertices and triangles from the txt file correctly, though I had
to double the buffer size for each. It was hard-coded at 1500 each which was much too small causing an error. I will need to automate
the buffer size allocation by counting lines in the text file. That will alleviate the size allocation problem in the future for polygon meshes.

Since it fails to render the polygon mesh correctly and only returns colors very similar to the background color I suspect that the problem
may be an error in the Triangle Intersection Algorithm. It fails to detect an intersection with the polygon surface so it returns the background.

https://www.scratchapixel.com/lessons/3d-basic-rendering/ray-tracing-rendering-a-triangle/ray-triangle-intersection-geometric-solution
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 05, 2021, 12:23:23 PM
I understand miker, you're doing an excellent job, you're definitely developing everything from the beginning, if you want on aminet there is a source of a program that makes use of wazp3d I don't know if it is written in c however it is a complete rendering program, of course it's not blender but her work is very well :)

https://aminet.net/gfx/3d/Skulpt_doc.lha
https://aminet.net/gfx/3d/Skulpt_src.lha
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 05, 2021, 12:30:35 PM
I don't want to create confusion about what you are doing, so maybe you can examine the archives I posted on it just for the purpose of learning or if you are easier to take a compile, skulpt3d does not need MUI anyway, it has always requested enough enough Accelerated or with 060 or with PPC included Warp3D, we have the power of X86 and WAZP3D :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 05, 2021, 04:50:14 PM
I don't want to create confusion about what you are doing, so maybe you can examine the archives I posted on it just for the purpose of learning or if you are easier to take a compile, skulpt3d does not need MUI anyway, it has always requested enough enough Accelerated or with 060 or with PPC included Warp3D, we have the power of X86 and WAZP3D :)

The Skulpt3D sources would be great for reference. But it is written in C++ as are many 3d rendering softwares.

Thanks for the links.

I'm trying every avenue of approach to solve the problem of rendering the polygon mesh using triangles.

I'm studying the Moeller-Trumbore Algorithm to find out if the raytracer code needs to be revised. It may be possible to optimize the render code by using a bounding box and hit test.

It currently imports a txt file that is a modified OBJ file in text format. That's another thing that could be improved upon - reading OBJ files.

I'm getting closer to a solution for the rendering problem. The raytracer requires 2 pieces of information. It needs the results of hit test for intersection from both sphere and triangle. But it also requires distance. For ray_sphereIntersection the distance values vary accross the image with an average double value of 0.000085 and the spheres render correctly.

The raytracer application uses distance to determine if the intersection is in front of or behind the background. If the distance is closer the ray hits the surface. If farther away it hits the background. Rendering the polygon mesh with triangles only returns background colors. But the distance remains constant at 0.000001 and that seems odd. Given a 3D Surface there are high points and low points. We expect the distance to vary accross the scene. But for ray_triangleIntersection it doesn't change. So the pixel is always behind the background.

So it seems the distance calculation for triangles is incorrect. 
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 05, 2021, 08:36:21 PM
I understood indeed I see that you are proceeding by degrees and this is a good thing, I hope you can solve the problem :-\
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 05, 2021, 08:40:54 PM
But some posts before you were talking about code from MacOSX, you found something interesting?
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 05, 2021, 09:13:33 PM
But some posts before you were talking about code from MacOSX, you found something interesting?

The raytracer code that I ported from Mac OS (x-code) is what I'm working with now. It renders spheres ( built-in) scenes using ray_sphereIntersection. But in order to render a polygon mesh of vertices and triangles that it loads from txt file it uses ray_triangleIntersection. Somewhere in that function there is an error. It renders spheres but it won't render triangle meshes.

Rendering spheres and triangles is the core of the raytracer so it needs to work correctly.

salvo,
I have to fully understand the Moller-Trumbore Algorithm before I can re-write the core of the raytracer. Lots of Vector Math. Here is the algorithm:

bool rayTriangleIntersect(
    const Vec3f &orig, const Vec3f &dir,
    const Vec3f &v0, const Vec3f &v1, const Vec3f &v2,
    float &t, float &u, float &v)
{
#ifdef MOLLER_TRUMBORE
    Vec3f v0v1 = v1 - v0;
    Vec3f v0v2 = v2 - v0;
    Vec3f pvec = dir.crossProduct(v0v2);
    float det = v0v1.dotProduct(pvec);
#ifdef CULLING
    // if the determinant is negative the triangle is backfacing
    // if the determinant is close to 0, the ray misses the triangle
    if (det < kEpsilon) return false;
#else
    // ray and triangle are parallel if det is close to 0
    if (fabs(det) < kEpsilon) return false;
#endif
    float invDet = 1 / det;
 
    Vec3f tvec = orig - v0;
    u = tvec.dotProduct(pvec) * invDet;
    if (u < 0 || u > 1) return false;
 
    Vec3f qvec = tvec.crossProduct(v0v1);
    v = dir.dotProduct(qvec) * invDet;
    if (v < 0 || u + v > 1) return false;
 
    t = v0v2.dotProduct(qvec) * invDet;
 
    return true;
#else
    ...
#endif
}
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 06, 2021, 01:53:37 AM
salvo,

After comparing the ray_triangleIntersection funtion in the raytracer to the two samples of the Moller-Trumbore Algorithm there were some inconsistencies. Most notably the value for EPSILON was wrong in the raytracer function. Also, some of the formulas for Vector3D values were slightly incorrect, missing values. Now I must revise the triangle function and verify it.  :)

The two samples of the original algorithm I'm using for comparison are from Wikipedia and Scratchapixel.com
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 06, 2021, 12:19:40 PM
I understand miker indeed mostly seems to me a bit complex for me but I think it will come out a great job :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 06, 2021, 08:45:22 PM
I understand miker indeed mostly seems to me a bit complex for me but I think it will come out a great job :)

I'm making progress. Here's my new theory as to why the polygon mesh loaded from text file refuses to render correctly.

After substantially changing the ray_checkTriangleIntersection function and comparing results I have concluded that other than the value of EPSILON the function works as expected. What was unexpected was that even the built-in scene "spheres" has a background composed of vertices and faces. Since the spheres scene renders correctly then rendering triangles also works correctly. So what is the problem?

I suspect the problem with rendering the polygon mesh loaded from file is not a problem with the vertices or faces or the way it is rendered. But rather it is a problem with the loading process.

To prove that rendering triangles works I will attempt to convert the sample polygon mesh into a built-in scene which means I will need to hand edit all the hardcoded values for thousands of vertices and faces. If I could find a sample polygon mesh of only a few hundred vertices and faces that would be much easier.

Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 06, 2021, 09:23:28 PM
If I open "marbvase.3ds" in 3DS R4 and identify the annular ring at the top of the vase I can find the corresponding vertices and faces in the exported object file which is just a text file. That will probably be just a few hundred vertices and faces to hand edit.

Then I will make a built-in scene of that to render the triangles.
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 06, 2021, 10:26:06 PM
Wow! I had no idea Windows 10 had a built-in 3D Object Viewer!

I was opening a text file and I accidentally tried to open the obj file by mistake. But it opened instead in the 3D Viewer. Nice!  :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 07, 2021, 06:40:26 AM
Don't laugh. I know it's not my best work.

It's supposed to be a blue three-sided pyramid. But the coordinates are off. So it's looking more like the "leaning pyramid of piza" or something like that.  :)

At least it proves that the raytracer is rendering triangles.

This 3D object has four vertices and four faces (triangles). You can see that it's 3-dimensional because it is casting a shadow.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 07, 2021, 01:06:30 PM
no miker you are doing an excellent job, I don't mean 3D graphics, perhaps when the program will be ready to light some guide or buy books :)
Title: Re: Mini-Ray Raytracer
Post by: aGGreSSor on July 07, 2021, 03:38:52 PM
Wow! I had no idea Windows 10 had a built-in 3D Object Viewer!
Unfortunately, there is no such datatype for Amiga. :( I was also surprised when I found out that files with the STL extension (which contained models for a 3D printer) easily viewed in Windows 10 without additional software.
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 07, 2021, 06:45:30 PM
Wow! I had no idea Windows 10 had a built-in 3D Object Viewer!
Unfortunately, there is no such datatype for Amiga. :( I was also surprised when I found out that files with the STL extension (which contained models for a 3D printer) easily viewed in Windows 10 without additional software.

The OBJ file extension could be associated with the raytracer using a datatype descriptor to view the 3D Object Files in AROS, when we get to that point.
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 09, 2021, 06:48:10 PM
First rendered polygon mesh imported from text file.  :) :) :)

Now that reading vertices from file has been fixed it's time to optimize the raytracer algorithms, remove hidden lines and surfaces, improved lighting, softer shadows, depth of field, improved materials, background images, and texture mapping. There is also a need to improve reflection and refraction and reduce the overall rendering time for large polygon mesh files.

After all that the focus will be importing Object Files and 3DSFiles, and SCN Scene Files directly into the raytracer.

Just a few little things...
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 09, 2021, 06:56:32 PM
well miker, you're working on the rendering engine?
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 09, 2021, 09:01:26 PM
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.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 10, 2021, 11:53:27 AM
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 :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 11, 2021, 04:34:52 PM
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.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 11, 2021, 05:19:08 PM
great miker :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 12, 2021, 11:40:50 PM
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.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 13, 2021, 12:41:18 PM
we hope well :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 13, 2021, 03:09:21 PM
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.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 13, 2021, 04:59:26 PM
Bravo Miker I understand :)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 13, 2021, 09:05:00 PM
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.  :)
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 13, 2021, 09:33:48 PM
Miker patience brings, I'm sorry you're finding difficulties on the code :-\
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 15, 2021, 03:12:53 AM
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.  ;)
Title: Re: Mini-Ray Raytracer
Post by: miker1264 on July 15, 2021, 03:23:04 AM
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.
Title: Re: Mini-Ray Raytracer
Post by: Amiwell on July 15, 2021, 12:33:47 PM
well miker I'm glad you discovered something new :)