Groverburger's 3D Engine (g3d) v1.5.2 Release

[me_smash_videogame]

Thanks for the kind words! At least half of the reason I made this engine in the first place was to really understand how 3D rendering works for myself, so it's cool that I can help someone else in that regard.

Ignoring UV data in .obj loading is luckily a relatively simple procedure. We can just swap out lines 115-117 of objloader.lua like so:

Code: Select all

compiled[#compiled +1] = concatTables(verts[face[1]], {0,0}, normals[face[3]])
compiled[#compiled +1] = concatTables(verts[face[4]], {0,0}, normals[face[6]])
compiled[#compiled +1] = concatTables(verts[face[7]], {0,0}, normals[face[9]])

And any UVs will automatically be set to 0 when a .obj file is loaded.

This however does not solve your problem of materials for faces. In order to create materials as you're describing them, you would need to split up your models to have exactly one material per model.

This is because of the fact that you can only (at least to my knowledge) have one shader effect a mesh at a time, and in order to do things like change specularity or diffusion per face you would have to apply a different shader to a different model containing that face.

Tangentially related to your material property idea, creating some property like coloring a face is extremely similar to the concept of UVs, and can be done with UVs by setting all UV coordinates on a face to point to the same pixel effectively making that face the color of that pixel.

There seems to be no way around needing some vertex property in your mesh determining the color of the vertex. Because of this, I would advise you to stick to UVs as programs like Blender already have support and really convenient tools for UV editing.

Hope that helps.

That code doesn't actually skip UV data, it just prevents detected UV data from being put into a list. I may not have mentioned that my models not only don't have UV data on export, but they're completely missing the lines as well which is what's crashing the obj loader. As for the face coloring issue, that's going to be my deal breaker with this. If you ever end up finding a way to do that then let me know.

[RNavega]

@me_smash_videogame: do you have a sample of an OBJ file with this flat color per face?
Also, what software are you using to export the OBJs?

[RNavega]

@groveburger what exactly is the history involving G3D and SS3D?
- G3D's code has more recent commits, while SS3D is older but has more features (it also supports that UV-less OBJ loader that people are talking about).
- I can't find a proper repo for SS3D but for forks to your G3D. For example: https://github.com/AndrewMicallef/ss3d

[groverburger]

@groveburger what exactly is the history involving G3D and SS3D?
- G3D's code has more recent commits, while SS3D is older but has more features (it also supports that UV-less OBJ loader that people are talking about).
- I can't find a proper repo for SS3D but for forks to your G3D. For example: https://github.com/AndrewMicallef/ss3d

Thanks for the question. g3d is a rewrite and renaming of SS3D.

SS3D's code was very messy, bloated, inefficient, and all-around cumbersome to use. The code eventually got bad enough that I didn't even understand half of it myself. I decided a few months ago that I should just rewrite the whole thing to be clean and easily understood, so I did. If you're looking for the source code for SS3D, just look back a year in g3d's commit history on Github.

g3d is equivalent to SS3D in terms of features, except for the simple lighting. I figured that it would be a lot more beginner friendly to leave out the need for light source definitions, and leave that process to the end user if they so desire. Furthermore, if someone wants some non-standard .obj file loading in g3d, it should be a simple modification.

[groverburger]

That code doesn't actually skip UV data, it just prevents detected UV data from being put into a list. I may not have mentioned that my models not only don't have UV data on export, but they're completely missing the lines as well which is what's crashing the obj loader. As for the face coloring issue, that's going to be my deal breaker with this. If you ever end up finding a way to do that then let me know.

Yes, which effectively skips UV data importing like you asked. I'm not sure what you mean by completely missing the lines. The obj file importer only reads vertices, UVs, normals, and faces.

For your specific engine request, it would require you to build your own custom file format, model importer, exporter, and engine. Instead of doing all that, I would recommend researching more mainstream ways of doing what you want to do so you don't have to reinvent the wheel.

I would suggest starting by learning UV mapping. It is the standard way to color and texture models, from g3d to Unity to Unreal.

[RNavega]

Thanks for the question. g3d is a rewrite and renaming of SS3D.

SS3D's code was very messy, bloated, inefficient, and all-around cumbersome to use. The code eventually got bad enough that I didn't even understand half of it myself. I decided a few months ago that I should just rewrite the whole thing to be clean and easily understood, so I did.

Ah, that makes sense. Thanks a lot for the info (and the engine too, it's a gem).

One thing I'm curious to test is if there's a performance increase by using love.math.Transform objects instead of Lua tables, since they can be used as 4x4 matrices.
People also recommend using FFI objects like C structs or C float arrays, but from what I tested, indexed reads and writes using FFI objects are not faster than plain Lua array tables. Maybe this is meant for when using vanilla luac, and not LuaJIT which optimizes things further.

[groverburger]

Ah, that makes sense. Thanks a lot for the info (and the engine too, it's a gem).

One thing I'm curious to test is if there's a performance increase by using love.math.Transform objects instead of Lua tables, since they can be used as 4x4 matrices.
People also recommend using FFI objects like C structs or C float arrays, but from what I tested, indexed reads and writes using FFI objects are not faster than plain Lua array tables. Maybe this is meant for when using vanilla luac, and not LuaJIT which optimizes things further.

Thanks for the kind words!

Honestly, love.math.transform objects are something I still have yet to research. I might look into a possible performance increase there in the future, but I am happy with where the engine is currently so I'm in no rush.

FFI objects might be a lot more efficient (and in my experience with storing mesh data they 100% are), but I am focusing on simplicity and source code readability with this engine so I currently feel that keeping everything in plain Lua tables is the best fit. If anybody wants to do some performance enhancements on their own fork, I'm all for it.

[pgimeno]

One thing I'm curious to test is if there's a performance increase by using love.math.Transform objects instead of Lua tables, since they can be used as 4x4 matrices.

In my experience, calling engine functions through the standard interface is slower than calling FFI functions or pure Lua code (with the exceptions of the random and noise gen. functions, and of getFFIPointer, that use FFI internally), because they interrupt traces.

[RNavega]

@pgimeno useful info, thank you.

[JJSax]

Thanks for the tool! I used ss3d to create my solar system scale, I'm excited that the project isn't dead! Great work!

If you're interested in what you made possible: https://youtu.be/c_zMSnKyZc8