Show HN: VSC – An open source 3D Rendering Engine in C++ | Hacker News Reader

Show HN: VSC – An open source 3D Rendering Engine in C++

github.com

101 pointsNormalExisting34 comments

Been making this rasterizer engine in C++ for the past few months, now also adding ray-tracing functionality to the system.

Simply load a model or generate a mesh, add some lights, and render.

Open articleView on HN

Funny coincidence. I've written a small 3D rendering engine for the ESP32 as well last week. It has standard 3d math, clipping, and rasterization of points, lines and triangles. all in ~1500 lines of code. The repo is not polished yet but you can find it here: https://github.com/aap/psiop

It's always exciting feeling to get some feedback from community, so here you go! The project looks fun, but could use a bit more docs. I was able to compile for esp but didnt test yet. I only have a cheap aliexpress esp with builtin lcd, might try to hack it

Yeah I might make some docs for it soon.

Great idea pulled off! Feedback si always the best way to see if you are headed for the right direction.

this is really cool thanks! totally i need of a good software renderer!. Not in c++ but this should be portable techniques i guess. my first attempts tryjng t draw 3d stuff to a framebuffer, needless to say, were so slow. didnt think it was possible to make something run that slow on a modern pc...

thanks! super cool project to learn stuff from =)

"totally i need of a good software renderer!"

If I may ask, why?

Don't you like performance?

i am writing an operating system and want to make a software (batch) renderer inside that to draw things. i am not confident nor currently have the objective to port something like Vulkan and write a device driver. my video card will give me a framebuffer via legacy interfaces, so i think software renderer is my option to do 3d

Well done!

You mention the point is to make it portable. Does the project have any other goals, like, what kind of games could be made with it, how fast does it need to be? Do you have any performance metrics to share?

Performance boosts and metrics I do intend to look into, in particular acceleration structures (probably a BVH?) for the ray tracer and more optimized methods (e.g. a better scanline triangle fill and some clipping algos) for the rasterizer.

As for portability, not sure yet, this is meant to more or less be a rendering/animation engine that is lightweight, probably portable to embedded processors like ESP32s?

Is this a recreation of the venerable POV-RAY https://www.povray.org/ (30 years old now, wow)?

povray is a raytracer, this is a rasterizer (like what openGL does, say). Different rendering techniques.

Docs have largely been uploaded.

VSC? IS THAT A MOTHERFUCKING GEOMETRY DASH REFERENCE?!? :O

(sorry, I had to)

Read the readme and find out :3

Interesting! Some feedback:

- Try to make it clear in the description that it's software rendering (it's easy to miss this information).

- The readme should include a clear list of features.

- Be aware that the AGPL license might be a problem for many people.

Not OP, but I think AGPL is generally an excellent choice for my hard work that I want to showcase.

If I care about free software but also want to "protect" my work to prevent people from forking it without releasing their contributions because of strong copyleft. Many of my open source personal projects are licensed under AGPL.

AGPL makes no sense to me for projects that aren't focused on server use. This project is a good example of something that could just have a GPL license attached to it.

I personally don't use AGPL software if I intend on trying to expand on something as a business idea. I'd be fully willing to give back bugfixes and donate back, but I'm not about to hand off anything I pour months and years into to my competitors for free.

> I'm not about to hand off anything I pour months and years into to my competitors for free.

Library authors can pour "months and years" into their projects, and yet you expect them (but not yourself) to give away their code under more permissive terms, while you keep yours closed? The (A)GPL is a great choice because it forces people like you to either (1) open up your code or (2) pay for a closed-source license.

I don't expect anyone to do anything, but if they do I intend on respecting the license. I also expect myself to give back however I can. I just don't see how you dismiss someone else's efforts. It's like valuing a home you bought and did work on, solely on how it looked before you bought it. Even if you tore down most walls and redid the flooring and interior drastically.

If copyleft is desired, the EUPL is very similar to the AGPL, but isn't viral, so you can link it as a library to a closed-source program. It's also compatible with most open-source licenses.

Not sure if it's what the OP wants, but I think it's a neat license and I don't see it used anywhere.

> Be aware that the AGPL license might be a problem for many people.

Nothing prevents the author from selling closed-source licenses, as long as they retain sole copyright over the code.

> - Be aware that the AGPL license might be a problem for many people.

I'm more confused as to why it applies to this tbh. GPL would have sufficed no?

Working on some rudimentary docs right now, the README might also be updated directly.

If portability is a goal you might want to use CMake and Docker.

make is more portable than cmake. docker has zero value add from what I saw in the repo.

How about fixing the version of the compiler and the dependencies so you don’t get build errors ?

Yes it only works for Linux. But these days it’s pretty easy to get a Foam with WSL on Windows and Docker for desktop

Sticking with a Makefile is going get increasingly unwieldy for a large project

Make is quite a bit more headache these days to consume then make (in modern code bases anyway).

I'm not actually a fan of make, I think mk is a much better language, but everything is relative. I still prefer make over any meta-build system or garbage like boost jam. In my experience the problem of modern codebases is that they're structured like crap in the first place. Too complicated and for very little real reason. OP's codebase is actually trivial, so the problem doesn't really exist. It would be trivial to adapt it to use msvc, but if you have make on windows, chances are you already have gcc so there's not much point unless you REALLY want to use microsoft's compiler.

Definitely not true in my experience.

Want to describe your issues with CMake?

Maybe the community can help you.

It's inherently less portable as it relies on C++ and the cmake language is rather complicated, and thus making it harder to implement. Make and more preferable mk, are reliant on C, and are simpler languages making them easy to implement. It's simple portability calculus.

Portability-wise this was perhaps the case ~20 years ago but today I am not aware of any platform that doesn't have a decent C++ compiler so I don't think what you're saying is generally true.

I also don't agree on the second point - I don't see what makes the CMake "harder to implement" than make/mk. It's already implemented and all you need is a compiler, which we have plenty of.

> I am not aware of any platform that doesn't have a decent C++ compiler

Plan 9

> I don't see what makes the CMake "harder to implement" than make/mk

If you can't use the existing codebase, then you have to implement cmake from scratch, which is orders of magnitude more difficult than implementing a mk interpreter.

I hope you're aware how loose of an argument this is.

> Plan 9 is a research operating system, and exists to answer questions about ideas in OS design. As such, the Plan 9 experience is in essence an exploration of the interesting ideas it puts forth. Most of the ideas are small.

> ...

> Plan 9 failed, in a sense, because Unix was simply too big and too entrenched by the time Plan 9 came around. It was doomed by its predecessor. Nevertheless, its design ideas and implementation resonate deeply with me, and have provided an endless supply of inspiration for my own work. I think that everyone owes it to themselves to spend a few weeks messing around with and learning about Plan 9. The dream is kept alive by 9front, which is the most actively maintained fork of Plan 9 available today. Install it on your ThinkPad and mess around.

[0] https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html

Reply on news.ycombinator.com