I am planning to design a new engine (what i am doing with my life?!) and in this new engine (which will be just actually a heavily refactored version of the current one), i will finally enable my software rendered ray tracer alongside with my current existing software rendered rasterizer.

It can be flipped on and off any time i want, by just flipping a variable, that decides which rendering path i use.

I designed the rasterizer to be backwards compatible to even 32 bit cpus and a few 100ish mhz cpus. It consumes about 20 mbyte of ram, as i use small unfiltered textures, and generating low poly count objects.

In contrast, the ray tracer requires 64 gb ram and a 24 logical core cpu. It can not be back scaled below this to produce enjoyable output. Therefore, if these machine requirements are not being met, it switches back to the rasterizer which targets your grandmothers old cyrix cpu.

Was someone already in similar situation? If yes, do you tried to create a medium graphics settings somehow? How did you communicated the big difference to the users?

LorenzoGatti said:
ray tracer requires 64 gb ram

This seems ridiculously large unless you are doing something brute force with huge voxel worlds, or dealing with enormous meshes (100 million triangles or more). I've done plenty of CPU ray tracing with modest memory needs. Perhaps there is some room for improvement in your ray tracing algorithms or scene representation?

LorenzoGatti said:
for example, I have a profound dislike for Playstation graphics with creases and texture discontinuities in random places

well my current old engine looks just like that, and it looks very awful, but it was fitting for its purpose years ago.
now it doesn't fits the purpose any more, people are expecting something better looking visual experience.

this old technology however canot really be scaled. the only scaling i could do is to add some texture filtering and increase the polygon count, but it wouldnt really help on it, as this is pure integer logic optimized for like the first gen atoms and such.

LorenzoGatti said:
Can't you ray trace less geometry, with some compromises

I can, but then it will be just as ugly, or even more ugly than the graphics above, and it would still be too slow to act as a medium graphics level.

So i basically cant seem to be able to scale the rasterizer up enough to act as a medium-graphics quality solution, and i cant scale down the ray tracer to act as a medium-graphics quality solution, and i am not fond of creating a third solution to cover the medium graphics at all.

Aressera said:
unless you are doing something brute force

Yeah i am bruteforcing the ray tracer, with a grid accelerator structure. I had several ray tracers earlyer, using far more sophisticated tree structures and tricks, long story short, ended up returning to simple bruteforce methods because it wasnt notably slower, but the code is like 99% easier to maintain, and more or less bugless.

Have you considered that you might just be really, really bad at writing efficient code? Your old software rasterizer should not look as bad as it does on a 100MHz CPU with 20MiB RAM. If your new raytracer looks that bad with less than 64GiB RAM, then either you have a horribly inefficient raytracer, or raytracing is the wrong approach for your problem, or both.

a light breeze said:
really bad at writing efficient code

graphics output depends on the content as well, not just on the engine. feeding it with terrible quality models and images are not question of engine design, more like game design. i will also improve the model and texture quality, but that is irrelevant in this context, and it will not improve the overall quality in rasterizer mode too much anyway.

when using approximately the same content, it runs about 10x faster than final fantasy 7 software renderer on the same 200 mhz computer with the same model and graphics quality (i have benchmarked it), so i dont think i really bad at writing efficient code, OR squaresoft is 10x worse than me lol. at the same time, the code performance is far away from the efficiency of quake1 software renderer, so there would be a lot of room to optimize that part of the code. i want to switch to ray tracer anyway, because IN THE LONG TERM it can give me better benefits in regards of polygon count and effects. and how my new ray tracer looks - its not yet finished - the 64gb ram doesnt changes too much how it looks, it changes its speed and efficiency.

however

tonight i had an idea. i think i could add flat shading, or even normal support to the code, and that would give me relatively better results on the rasterizer…

Finally i got to the point of realization.

Medium preset is not possible due to the impossibility to scale the old renderer up, and the new renderer down.

The solution is, create two new presets.

-The old one will be the lowest. I will add a few more effects (such as proper pervertex lighting) and some texture filtering to it, and that will be the low setting.
-The ray tracer will have a high and a highest preset, which can be selected even if there is not enough ram (in that case, the acceleration structure size will be lowered to ensure the game fits in the ram).

Thankyou for your feedback Lorenzo.

When i mentioned engine, i was referring to the actual engine, not to this particular game maker around it. I plan to keep the compatibility with my old stuff to some extent, but i dont think i will move that rpg maker onto the newest code base. Or anything i have done so far. It will be used for new stuff in the future. Even if i could drag these old stuff too, i plan to change how the system works, and currently i am relocating functionality into the engine from the modell loader, for example to have support for normals, generated mesh optimization, geometric lod, etc, these all will be done by the engine itself on threads, instead of doing it manually with a function.

Generating the models will also be more cpu hevy than before (and they will look better), and these kind of features would slow down that game maker - also the new code base will not be stable and reliable for quite a while, so it was better to just start a new project for it. Also, teaching average joe about lighting and such, wouldnt be a viable option, not to mention how less sense would do to add ray tracing to that code (cash shadows? where? how?). So that maker will be kept on my previous engine.

Two little せいれい is living inside my head.

One of them recommends to pipelinize the rasterization even more. Try reorganizing the commands, try searching things that can save you one or two clocks everywhere, do everything you can again and again, and everything will sort out itself.
The another one says: just make 30 additional threads, and enable the new geometric lod, and alles in ordnung kommen.

I should have realized it years ago: both of them are evil.

Normal loading are working now, normal generation works too, light and normal interaction works. This is what i was able to come up with so far. Its enjoyable. It will do as a new low graphics quality settings.

One problem is, if the vertex count increases above 20-30k, the speed starts to nose dive (partially because i have sacraficed the vertex setup for more easy pixel fill). Above 120k or so polygons from this shaded dragon, the speed fells down below 60 fps (even if the light color is cached). So i will have to do something against that, because i plan to use at least half millions of polygons on the scene in the future.