Android Question Raytracing

[MasterGy]

Hello!

I came across this picture of spheres on the ground the color of a pepita already 30 years ago.
It is interesting that this was an 'image generating' program. It took a long time (even several minutes) to render the image.

What was interesting about the picture was that it followed the path of the light back. What we can see. He did not project an object onto the screen, but the display through which we see the image, he examined pixel by pixel by light reflection to see if he could find a light-emitting object. In this case, the light-emitting object is the ground and the sky. The Sphere we see is a reflective phenomenon. This entire graphical approach is called raytracing.

Many years ago, on the QB64 forum, someone rewrote this very old code, and the program painted a picture for us. I looked for the parts in the code that could be used to change the point of view and make the spheres move. I've simplified and combined everything I could find so that there is as little calculation as possible. The program worked on QB64.

An old image generation code that comes to life on the screen with the development of computer technology. After getting to know b4X, I rewrote the code so that it can also be run on a phone. Lots of calculations! A lot! I was curious.
Based on my experience, I feel that the phone performs math calculations quickly. What hinders the task is the 'engine' I use.

The display is done in such a way that a timer starts a 'sub' (three) at a specific interval. when drawing is finished, redraw. if not, skip it. Thus, the UI and movements are constant. The timer is constant, 60 FPS. And there will either be time to draw (if you have finished the previous one) or not (then skip it).

Rendering (threed) draws on a bitmapcreator. When you're done, you put it on the activity.

This is how it works. However, I noticed that a lot of time is spent not with mathematical calculations, but with drawing a pixel.

Only the 'three' library needs to be attached to the program, I have included it!

I would like to ask what is the fastest pixel drawing solution. Canvas is slow. Bitmaprecreator is functional but takes a lot of time. What trick could I use to load a bitmap with new pixels as quickly as possible. Draw a pixel directly on the screen?

 

[MasterGy]

Thanks for the help!

I understood a few things in the raytracing code. I added the
- remote dimming
-use of soil texture
-the size and alpha of the ball shadow
- the spheres can be colored

The code is small, but there is a lot of calculation going on. Calculating the color of 1 pixel is a lot of operations. As a matter of fact, I'm amazed at the performance of the smartphone, because I was expecting a much lower performance.

I added that using 'thread' the rendering takes place on several threads. When each thread is finished, draw it. I got about three times the speed. The number of processing threads can be set from 1 to 10.

It can be stated how much 'light reflection' the 'light-absorbing' rays can perform. (you are standing between two parallel mirrors, the number of light reflections is infinite). It can be limited here. 5 is good. More than that is pointless. But more than 5 is not enough, because the picture will be incomplete.

All rendering-related settings can be adjusted in real time. I would like to receive feedback on what phone/tablet (when it was released, what type) and with what settings it runs enjoyably.

My questions:

-is there a more effective 'thread'-starting option? I feel that 'thread' does not fully utilize the performance of the phone's 8-core processor (2 fast, 6 slow).

-OpenGL! Currently, the program uses 'bitmapcreator's' pixel drawing. I think it's basically the fastest pixel drawing engine out there, but it's slow for this task. If I eliminate all 'bitmapcreator' operations in the program, I achieve about 130% speed. Direct byte-buffer drawing is possible in OpenGL. (FBO drawing). Draws the contents of an array asynchronously, in a direct hardware connection. Unfortunately, running it generates an error. I don't understand why. I'm looking for someone who has used this OpenGL feature before and can help.

If the image quality could be improved, a simpler game could be built on it. If nothing else, it's good for phone speed testing.

 

[MasterGy]

Hello!
I put some spectacular things in it. Adjustable FOV (angle of view), multiple textures. I also added that when rendered horizontally, if you want, it skips every second calculation. However, the color of the omitted pixels will be the average of the two neighboring pixels. Averaging 2 pixels is faster than averaging 1 pixel. So there is no resizing, but a small quality loss in favor of higher fps. All changes are made in real time.

Unfortunately, OpenGL direct pixel drawing is always hindered by something. There are several approaches, no matter which one I start with, the system simply lacks the opengl instruction that is needed to make it work.
For example, 'GLDRAWPIXEL' is missing. Is this intentional? Do they intentionally exclude those possibilities when the operating system does not override it? So drawing on the screen must inevitably go through a 'layer', a filter? Directness does not work. I would like to know if I am wrong or if this is intentional?